资源分类

数字时代应用可持续性架构与验证 白皮书 2022.12 iResearch Inc.2022 年数字时代应用可持续性架构与验证白皮书 1 目 录 第一章 数字化时代的应用可持续性.4 一、应用可持续性概述.4 二、应用可持续性背景.5 1、中国数字经济迅速发展.5 2、产业数字化进入了深水区.6 三、应用可持续性价值.7 1、应用故障为企业带来直接经济损失.7 2、政务、金融领域的应用可持续性关系国计民生.8 第二章 应用可持续性挑战.10 一、敏捷挑战.10 二、信创挑战.11 三、疫情挑战.12 第三章 应用可持续性架构设计思想与特征.14 一、应用可持续性架构设计思想.14 1、抽象与分层.14 2、不同层解耦.14 3、同层节点冗余、替换、水平扩展与异构.15 4、中间层和核心节点的稳定性保障.17 5、持久化存储且共享.18 二、应用可持续性架构特征.18 1、跨域协同与平滑迁移.18 2、多协议支持.23 3、与现代高可用架构无缝对接.26 4、可观测性和分析.27 5、负载可编排.30 6、主动韧性.32 7、开放与集成.33 第四章 应用可持续性架构验证指标体系.34 一、性能测试.34 1、四层吞吐性能测试.34 2、四层新建速率性能测试.35 3、四层并发性能测试.35 4、七层吞吐性能测试.36 5、七层新建事务速率性能测试.38 6、七层并发性能测试.40 二、基础功能测试.41 2022 年数字时代应用可持续性架构与验证白皮书 2 1、网络端口聚合功能.41 2、基本负载均衡算法(IPv4/IPv6 双栈）.42 3、Virtual Server 功能.43 4、健康检查基本功能(IPv4/IPv6 双栈）.44 5、SNAT 池基本功能.45 6、Cookie 会话保持功能.46 7、HTTP header 会话保持功能.46 8、源地址插入和提取功能.47 9、连接镜像功能.48 10、服务器温暖上线.48 11、SSL 卸载功能.49 12、动态路由功能（IPv4/IPv6 双栈）.50 13、主备模式高可用功能.51 14、N M 集群功能.52 三、超高可用架构场景测试.53 1、超高可用架构协同集成功能.53 2、Kubernetes 环境集成实现四层虚拟服务器自动创建.54 3、Kubernetes 环境集成实现七层虚拟服务器自动创建.54 4、Kubernetes 环境集成实现真实服务器自动扩容和缩减.55 5、集中管理平台统一纳管功能.55 6、TML-ADC/BIGIP 设备批量升级功能.56 7、TML-ADC/BIGIP 配置备份功能测试.57 8、NGINX/TML-ADC/BIGIP 日志管理功能.57 9、集中管理平台告警功能.58 四、管理功能测试.59 1、配置文件备份和恢复.59 2、数据统计和报表功能.59 3、网络管理扩展功能.60 4、运维管理工具.60 5、Syslog 功能.61 6、SNMP 与 NTP 功能.61 7、API 接口.62 8、Web/CLI/API 管理功能.62 第五章 展望.64 特别鸣谢.66 附录：应用可持续性架构测试示例.67 公司介绍/法律声明.79 版权声明.79 2022 年数字时代应用可持续性架构与验证白皮书 3 免责条款.79 合作说明.79 联系我们.79 微信公号.79 2022 年数字时代应用可持续性架构与验证白皮书 4 第一章 数字化时代的应用可持续性 一、应用可持续性概述 应用可持续是指企业利用 IT 资源，保障应用稳定运行，可持续地满足客户的需求与期望。应用可持续与高可用的联系与区别在于：高可用是应用可持续的必要非充分条件，而应用可持续不仅包括了基础设施侧的稳定性，还包括了用户侧的体验，是更为严苛的要求。应用可持续性仍然可以使用高可用的 SLI、SLO 和 SLA 等进行衡量，但 SLI 的具体指标可更宽泛。SLI（Service Level Indicator，服务水平指标），对于业务来说是最重要的指标，对于一般应用来说，是正常响应的百分比。SLO（Service Level Object，服务水平目标），是围绕 SLI 构建的目标。通常用 n 个 9 的百分比表示，并与一个时间范围挂钩，比如月度、季度、年度等。SLA（Service Level Agreement，服务水平协议）是企业围绕 SLO 发布的协议，它是要求在不满足 SLO 时向客户补偿的协议。需要强调的是，随着敏捷开发、CI/CD、DevOps 等理念的兴起与逐渐落地，应用可持续实际上需要在敏态中完成。比如，A/B 测试、灰度发布时，业务应是平滑的，客户是无感知的。应用可持续性架构，是指为了满足应用可持续，而采用的系统的、整体的 IT 架构，主要通过全生命周期健康检查与可观测、双活双轨、动态负载、主动韧性等手段，来摆脱对个别产品稳定性以及对个别运维人员的强依赖。应用可持续性架构，可以看作是软件工程 2022 年数字时代应用可持续性架构与验证白皮书 5 思想在 IT 运维领域的具体实践。应用可持续性架构验证，是指客户在选择应用可持续性架构及产品时，进行验证的方法论和具体指标。二、应用可持续性背景 1、中国数字经济迅速发展 2016-2021 年，中国数字经济发展取得新突破，数字经济规模实现翻倍增长。2021年中国数字经济规模由 2016 年的 22.6 万亿元增加至 39.2 万亿元，数字经济增加值占 GDP 比重由 30.3%上升至 39.8%。“数字中国”建设不断推进，在推动经济高质量发展、构建新发展格局中发挥了重要作用。在数字经济迅速发展背景下，技术进步、数字适老化及信息无障碍服务持续完善等因素驱动我国网民规模稳步增长。根据第 50 次中国互联网络发展状况统计报告，截至2022 年 6 月，我国网民规模为 10.51 亿，互联网普及率达 74.4%，较 2021 年 12 月提升 1.4 个百分点。其中，手机网民规模为 10.47 亿，同比增长约 4%。随着数字化进程加快及互联网、移动互联网等信息通信技术的更迭，我国数据量呈爆发式增长态势。2020 年我国年数据量为 12 ZB，占全球数据量 24%，预计到 2030 年数据量将增长至 175 ZB，年复合增长率约 30.7%，占全球数据量比重将上升至 29%。数字时代已然到来。2022 年数字时代应用可持续性架构与验证白皮书 6 数字经济是当前经济发展的新动能，而数字基础设施是数字未来的坚实底座。截至 2022 年 6 月，我国累计建成开通 5G 基站达 185.4 万个；网络基础设施全面向 IPv6 演进升级，IPv6 地址数量为 63079 块/32，IPv6 活跃用户数达 6.83 亿；互联网宽带接入端口数量达 10.35 亿个，光缆线路总长度达 5791 万公里。数字基础设施建设实现跨越式发展。数字经济和数据量的快速增长，使得应用可持续性的重要性得到提升，原来作为辅助的数字世界和物理世界变得同样重要，而近几年的新冠疫情，使得数字的重要性进一步得到提升。另外，数字经济和数据量的快速增长，也使得应用可持续性面临前所未有的挑战：一方面原有的软硬件产品和架构难以承担数据量的爆炸式增长，而另一方面在老新迁移的过程中要求业务不能中断。2、产业数字化进入了深水区 产业数字化是在满足原有产业组成结构的前提下，传统产业通过数字技术进行升级改造或将数字技术应用至现有产业中，从而为产业带来产值增加和效率提升。近年来数字技术不断赋能传统行业产能增长，我国数字经济与实体经济融合发展也渐入佳境，作为推动数字经济发展的主动力，产业数字化在数字经济结构的比重连年上涨。根据中国数字经济发展白皮书（2022）数据，产业数字化较数字产业化始终占据绝对优势，2021 年产业数字化占数字经济比重达到 80.9%，同比增加 0.7 个百分点，较 2017年上涨 3.9 个百分点，我国产业数字化的转型持续往纵深发展。2022 年数字时代应用可持续性架构与验证白皮书 7 随着未来大数据、人工智能等新一代信息技术的发展，传统产业对数字化改造的需求日益增加，叠加新兴技术在各传统产业的批量应用，数字技术将与传统产业彼此融合，相互促进，进而持续推动实体经济转型升级，产业数字化在数字经济结构的比重有望继续上涨。产业数字化的主体是传统行业，相比于互联网等原生数字行业，IT 人员占比更少，技术水平更低。IT 也往往非其业务本身，而往往是保障性环节，因此，不可能无限制地增加开支。这些也都要求不能完全依赖于开发、运维人员本身的 IT 素养，而需要以更加健壮、简洁的架构，来保障应用的可持续性。三、应用可持续性价值 1、应用故障为企业带来直接经济损失 在数字化时代的今天，应用的稳定性和可持续性变得极为重要。早在 2018 年，保险公司劳合社与风险建模公司 AIR Worldwide 就联合发布了一份报告，预测了主要云服务器出现故障后可能带来的损失。报告表明，如果三大云供应商（Amazon，Google，Microsoft）发生一起 36 天的云故障，将导致 190 亿美元的损失。2021 年 10 月 4 日，Facebook 长达 6 小时的宕机，直接导致其股价暴跌 6%。2022 年数字时代应用可持续性架构与验证白皮书 8 除长时间宕机影响较大外，短时间的访问延迟，也会影响用户体验，并进一步带来经济损失。数据表明：74%的用户会离开 5 秒内未能打开的网站；86%的用户会卸载出现过3 次以上性能问题的应用。以上，还仅是在一般的社交、电商等领域，而在证券等领域，对延迟更为敏感，对可持续性要求更为严格。2、政务、金融领域的应用可持续性关系国计民生 随着数字化对人们生活的日益渗透，应用可持续性不仅在一般商业领域与经济效益直接相关，而且在公共服务领域关系国计民生。2021 年 12 月 20 日和 2022 年 1 月 4 日，西安一码通出现了两次崩溃，使得民众不得不挨个手动登记身份、重采核酸，带来很大的不便与混乱。与之类似，2022 年 9 月和 11 月，四川天府健康通也因为流量过大，出现部分用户暂时无法登录的现象。根据凤凰网信息，天津、杭州、哈尔滨、澳门等地也先后出现崩坏问题，这些，都暴露出系统架构不健壮的问题。2022 年数字时代应用可持续性架构与验证白皮书 9 公共服务，不同于电商等领域，不能单纯以 ROI 去衡量，去提供有损服务。未来，随着 5G、物联网在自动驾驶、远程医疗等领域的应用，应用的可持续性会更加重要，甚至关系到生命安全。2022 年数字时代应用可持续性架构与验证白皮书 10 第二章 应用可持续性挑战 不管是从经济效益、企业声誉，还是从社会价值来说，应用可持续性都极为重要，但是，应用可持续性的落地却并不容易，它要求从数据中心，到 IT 基础设施，再到容器、数据库等 PaaS 层，最后到应用，都可持续，而这一切，又是在用户数量、网络流量不断增加，应用复杂程度不断增加，IT 软硬件技术快速更新迭代的整体背景下。一、敏捷挑战 业务开发和运维支撑，本身需求就是天然相悖的。极端来说，研发部门想要：“随时随地发布新功能，没有任何阻拦”，而运维部门则想要：“一旦一个东西在生产环境中正常工作了，就不要再进行任何改动。”由于两个部门使用的语境不同，对风险的定义也不一致。在现实生活中，公司内部这两股力量只能用最传统的政治斗争方式来保障各自的利益。运维团队常常宣称，任何变更上线前必须经过由运维团队制定的流程，这有助于避免事故的发生。例如：运维团队会列出一个非常长的检查清单，历数所有以前曾经出现过的生产事故，要求研发团队在上线任何功能之前必须将所有这些事故模拟一遍，确保不会重现。这个清单通常没有任何标准，每项事故的可重现程度、问题价值并不一定是一致的。而开发团队吃过苦头之后也很快找到了自己的应对办法：开发团队宣称他们不再进行大规模的程序更新，而是逐渐转为功能开关调整、增量更新，以及补丁化。采用这些名词的唯一目的，就是为了绕过运维部门设立的各种流程，从而能更快地上线新功能。1 除以上人的因素外，软硬件的利旧和业务需求以及技术本身的飞速发展，也是一对稳与敏的矛盾。以银行业为例，国有银行和股份制银行普遍建设有动辄几十亿甚至上百亿的数据中心，并在软硬件资源上具有大量投资，它们不可能抛弃历史，直接做架构的硬切换，比如，即使不考虑安全、可控等要素，它们也不可能直接切换到公有云。与此同时，在互联网时代成长起来的客户，却迫使银行的业务侧增加了大量新的需求，比如小额支付、活动促销、秒杀等。在需求增加的同时，新技术也层出不穷，Docker 在 2013 年开源，Kubernetes 在 2014 年开源，而如今，它们已经是互联网领域的主流技术，另外，NGINX、Istio、Opentelemetry、Prometheus、Grafana、MongoDB、Redis、TiDB、OceanBase 等开源技术也不断降低开发运维难度、提升业务的敏捷性，并降低企业的运营成本。但是，这些新技术没有经历足够长时间的检验，并且个别点可能也不符合合规性要 1（美）BERSYBEYERCHIRISJONES（美）JENNIFERPETOFFNIALLRICHARDMURPHY 著；孙宇聪译.SRE Google 运维解密M.北京：电子工业出版社,2016.10.2022 年数字时代应用可持续性架构与验证白皮书 11 求。此时，银行便有了“既要跟上新技术，又要不直接放弃已有的数据中心和软硬件，还要稳定、合规，不出现闪失”的复杂性挑战。二、信创挑战 在业务需求和新技术均快速变化的同时，信创也为金融、能源等企业的 IT 系统引入了新的复杂性。信创，即信息技术应用创新，是我国企业为了应对国外技术限制（如美国“实体清单”）而自发组织的国产替代行为。我国的信创，大致可以分为四个阶段：第一阶段，大致为 1999-2010 年，当时仅可做到单品可用，以及面向特定场景，解决了有无的问题。第二阶段，大致为 2011-2013年，该阶段做到了系统可用和成体系试用，尤其是在办公自动化和经营管理类等系统中。第三阶段，大致为 2014-2017 年，当时叠加互联网企业的去 IOE 浪潮，开始向基础领域演进，此阶段实现了基本可用到好用。第四阶段，在 2018 年之后，在多场景中开始规模化应用。不过，在信创的高速发展中，仍面临着业务连续性、业务创新和安全防范的挑战。目前，在我国的诸多强 IT 依赖行业中，英特尔、英伟达、甲骨文、IBM、戴尔、威睿、红帽、SUSE、F5 等海外公司，各自在不同领域，为客户提供稳定的产品和优质的服务，而国内对应产品良莠不齐，平均水平跟这些公司还有一定差距。因此，我们应正视差距，并设立科学、严谨的验证标准：首先，在业务连续性方面，2022 年数字时代应用可持续性架构与验证白皮书 12 应设立各环节产品、服务的完整、科学的验证标准，在一个相对稳定的架构下先小规模试验、改进、扶持，动态调整信创业务比例，稳步扩大信创覆盖范围，面对业务不确定性，应可秒级恢复业务，并排除故障，找出故障原因。其次，在安全防护方面，面对黑客无差别攻击，需提高安全网关性能及可靠性，并采用异构能力，提高系统的对抗能力。再次，在业务创新方面，应积极地拥抱分布式、微服务等新兴架构以及开源生态，但又要通过镜像扫描、代码审计等，降低因开源带来的风险。三、疫情挑战 受疫情影响，IT 基础设施线下运维、巡检人员减少。疫情期间，为了避免聚集，运维领域出现了许多工作“新常态”，例如不少数据中心都采用 AB 岗轮班制、核心岗最小化办公或是工作方式转至“远距离、不接触”的线上办公模式，采取现场封闭办公、居家协同形式，到岗率从原先的 100%精简到 50%，甚至不到 10%。不少原来依赖于原厂运维或第三方运维的客户，为了避免人员的流动，降低人员感染风险，也在一定程度上失去外援，“孤军奋战”。而与此同时，互联网流量陡然增长。由于疫情反复无常，大众的办公、金融、医疗等生产、生活的各个方面，对线上、对网络的依赖程度明显增加，整个社会转入线上运行的趋势陡然加速，互联网流量也由此以倍数级大幅提升。根据国家发改委，2022 年 1-6 月我国移动互联网累计流量达 1241 亿 GB，较 2021 年 1-6 月的 1033 亿 GB 增长 208 亿GB，同比增长约 20.1%。线下运维、巡检人员的减少和互联网流量的陡然增长对服务器计算、存储和网络的水平扩展以及应用可持续性带来了新的需求与挑战。IT 基础设施管理人员对停电或极端天气事件等各种灾难有比较明确的应急预案，但前所未有的新冠疫情为数据中心等基础设施的部署和运维工作提出了更高的要求，诸多挑战“跃然纸上”，亟待解决。例如，如何确保系 2022 年数字时代应用可持续性架构与验证白皮书 13 统安全维护始终在线？当遇到大并发的外网访问时，如何对远程办公下的业务系统应用做好统一监控？当出现高流量访问引发系统卡顿和事件告警时，如何在海量数据中快速查找问题原因，保障运维效率？等等。2022 年数字时代应用可持续性架构与验证白皮书 14 第三章 应用可持续性架构设计思想与特征 一、应用可持续性架构设计思想 应用可持续主要由三个方面构成：控制和调度面的可持续，一般对应 Mater-Slave 或Controller-Worker 架构中的 Master 或者 Controller；执行面的可持续，一般对应上述架构中的 Slave 或者 Worker；数据面的可持续，一般利用共享且本身冗余的持久化存储（如 etcd、Redis）来实现。1、抽象与分层 完整的业务应用需求传递链条为：用户/客户公司业务侧公司业务开发侧运维侧，在单体架构以及瀑布流式开发中，这种需求的变动，缺乏在任何一层“消化”掉的能力，而是一传到底，因此，业务之敏和基础设施之稳成为矛盾。而从另一个视角来看，当把业务看作稳态时（假定业务需求一成不变），基础设施侧也并不能保证一成不变，数据中心需要扩容，存储、计算、网络设备需要淘汰和更新换代。在早期，往往通过深夜停服等方式来进行，但随着人们对 IT 依赖程度的逐渐加深，这种方式可行性越来越低，基础设施之敏和业务之稳也成为矛盾。也就是，链条的两侧，其实均不关心对方具体发生了哪些变化，只关心给自己带来了什么变化，并希望自己可自由变化。此时，便需要一个中间层，来将双方的变化相互“翻译”。这种“翻译”的过程就是抽象的过程，而中间层诞生，就是分层。在 IT 架构中，负载均衡、容器编排、数据中台等，都是这种抽象与分层而产生的中间层，只是应用的场景不同。2、不同层解耦 当中间层一旦产生，中间层的上下便会变得简单而自由起来。所有共性的东西，每个节点一律不再关心，因为中间平台层已经实现；与上下其他 N 多节点之间的对接，每个节点也不再关心，因为中间平台层已完成“翻译”和对接，原来复杂的乘积关系变成了只与中间层对接的加和关系。2022 年数字时代应用可持续性架构与验证白皮书 15 这一相对统一的中间层，由于作用如此重要，因此往往成为业界事实上的标准，也往往成为“兵家”必争之地，Kubernetes、Marathon（Mesos）、Swarm 之争便是如此。一旦其中一种真正胜出，标准便相对统一起来，上下层短时间之内会出现大繁荣。平台意义的中间层，被取代相对缓慢，即使在日新月异的 IT 界也是如此，这也就让稳态和敏态的结合有了抓手。当然，在实际中，往往存在多个类似意义的中间层，比如在应用可持续中，应用交付网络/负载均衡可以看作第一个中间层，其可一部分流量分给传统虚机，另一部分流量分给容器云，而在容器云中 Kubernetes/Openshift 又可作为第二个中间层。3、同层节点冗余、替换、水平扩展与异构 一旦实现了抽象与分层、不同层解耦，那么中间层也就成为了 IT 架构的核心，只要它是相对稳定的，上下层的变化便可在该层“消化”掉，也即上层的变化不影响下层，下层的变化也不影响上层，这是稳态与敏态能够统一起来，也是应用可持续性的关键所在。上下层的节点作用被降低，平行节点间可冗余、可替换、可水平扩展、可异构：冗余：设置两个或更多相同功能的同类节点，这里的节点可以是数据中心（如同城双数据中心，异地双数据中心），也可以是分区（例如最保守的做法是在早期，让整个信创区完成与非信创区完全相同的功能，也即不让其单独承担实际职责）。冗余是保证高可用与应用可持续较为稳妥的方式，但如果在多层上冗余，则实际上往往有 4 个、8 个甚至更多副本，成本较高。2022 年数字时代应用可持续性架构与验证白皮书 16 替换：因为中间层是稳定层，因此上下层的任何一个单一节点、甚至一块区域都不再不可或缺，而变成了可以热拔插的组件，但需要节点将健康状态上报（对应健康监测和可观测），一旦出现故障，立即切换到其他节点。动态负载即是通过这种方式实现。水平扩展：当将故障节点的任务动态切换到健康节点，有可能对健康节点造成负载冲击，此时，必须可以迅速补充新节点。水平扩展属于自动化运维范畴，在不同层级往往有不同手段：例如物理机可使用 Cobbler 基于 DHCP 服务器和 PXE 环境迅速安装操作系统，远程启动等；虚拟机可以使用 Ansible 进行自动化管理；而容器云则可以直接使用Kubernetes 进行 Node 中 Pod 的扩展以及 Pod 中容器的扩展。异构：平行节点间也不再追求统一。架构本身不仅兼容异构，因为当某种攻击只针对其中一种软硬件产品时，异构类型便可幸免于难，成为“有生力量”，并担起应用可持续的 2022 年数字时代应用可持续性架构与验证白皮书 17 重任。这种包容异构的特点，其实为平滑迁移奠定了基础，不管是从传统虚机向容器云和微服务，还是从非信创向信创，迁移的过程，必然是异构状态。其实，蓝绿发布、灰度发布、A/B 测试等，均是利用的节点间可自由替换的特性实现的，只不过其往往是以相同的基础设施节点来运行不同的应用（版本），而上云、信创替代，则可用不同的基础设施来运行相同的应用。4、中间层和核心节点的稳定性保障 在以上架构中，有一个显而易见的问题是，并没有考虑中间层和核心节点出现故障的情况，如果 DNS 解析节点、核心负载均衡器、容器编排平台等出现故障。核心节点或核心中间层的可用性一般通过以下手段进行保障。（1）节点本身稳定 生产系统中的核心节点一般采用成熟、稳定、久经考验的产品和技术，并且版本升级策略一般也相对保守。例如：硬件方面，成熟的 SLB、ADC 设备均具有非常强的稳定性与可靠性。软件方面：Kubernetes 在 2016 年便有大量企业进行尝试，但真正将其布到生产系统中则大多发生在 2019 年前后；NGINX，从其诞生到在各企业中广泛应用，经历了十几年时间，而为了保证稳定性，其支持 HTTP3 协议的 NGINX-QUIC 很长时间单独存在，直到现在仍未合并到 NGINX 主干中。（2）轻负载，只做核心任务 由于核心节点具有全局性意义，其稳定的性能往往比丰富的功能更加重要，因此，普遍的一种做法是只让其承担调度和控制层面的事项，并不承担具体的工作任务。例如，四层负载，只负责流量转发，TCP 的三次握手等直接分发到七层负载或应用节点。再比如，在不少银行中，SSL 卸载不再放入负载均衡设备中，而是前后各一层负载均衡，中间一层SSL 卸载，构成三明治结构。还比如，在早期的服务网格 MOSN 中，让 Sidecar 承担更多负载，而减少对中心节点的依赖。2022 年数字时代应用可持续性架构与验证白皮书 18（3）冗余 冗余，即主从架构。对于核心节点，比如负载均衡设备，一般均采用冗余的方式，来保障系统的高可用。负载设备本身之间的冗余可用 VIP 地址漂移来实现，也即只有一台物理设备来占用 IP，当该物理设备出现故障，IP 漂移到其他健康物理设备。（4）产生新主节点 产生新主节点，即集群架构。如果主节点并非采用专用设备，那么在主节点出现故障时，自动根据算法将某子节点提升为主节点，这也是严格意义上的分布式。目前，这种方式在大数据领域以及区块链领域应用更为广泛。相比于主从架构，集群架构是严格意义上的分布式架构。5、持久化存储且共享 节点的配置和服务发现数据通过高性能 Key-Value 内存数据库进行存储，并持久化到硬盘中，数据间通过 Raft 协议保持强一致性的共享。在控制节点，可使用 etcd；而在执行节点，可使用 Redis。通过以上几步，节点的网络可以通过 VIP 漂移或者上层负载/编排平台的控制切换到其他节点，节点的任务可以通过本来的冗余或快速启动实例切换到其他节点，节点的数据因落到了共享的持久化存储中，也可被其他节点无缝继承。系统的健壮性和应用的可持续性，不再依赖于任何单一节点自身的可靠性。二、应用可持续性架构特征 1、跨域协同与平滑迁移（1）跨域双活双轨 数据中心双活架构：双活，是一种节约资源的计算机灾备方案。其实现模式是让主备两个数据中心都同时承担用户的业务，此时，主备两个数据中心互为备份，并且进行实时备份。一般来说，主数据中心的负载可能会多一些，比如分担 6070%的业务，备数据中心只分担 400%的业务，保证了当其中一边发生故障时，不至于造成业务无法处理的情况。与双活近似的是热备份和冷备份。热备份：备用数据中心对主数据中心实时备份，但不承担业务，当主数据中心业务中断时，自动切换到备用数据中心，是一种高可用但浪费资源的备份方式。冷备份：备用数据中心不对主数据中心实时备份，只定期备份，当主数据中心业务中断，人工切换到备用数据中心，是一种非高可用的备份方式。2022 年数字时代应用可持续性架构与验证白皮书 19 双活数据中心要做到网络双活、应用双活和数据双活。金融等行业，为了追求更高的可用性，且考虑成本，一般在双活之外再加灾备数据中心（俗称“两个半数据中心”）。信创区和传统区双轨架构：利用和数据中心双活类似的原理，在同一数据中心中的信创区和传统区（非信创区）等不同模块之间实现热备或双活的方案，即为双轨运行。双轨架构相比于数据中心双活实现上更为复杂，这是因为双活数据中心，只是物理距离较远，但网络、计算、存储设备一般较为统一，所以组网相对容易，而双轨相当于异生态组网，需要更全面的软硬件生态屏蔽底层的异构和复杂。2022 年数字时代应用可持续性架构与验证白皮书 20 交叉双活双轨架构：同时实现数据中心双活，以及信创区和非信创区双轨的架构，一般由多层负载设备和更复杂的软硬件生态来实现。（2）双轨平滑迁移 双轨是指信创区和非信创区同时运行，具体有以下几种模式/步骤：完全复制：信创区对非信创区的流量完全复制，进行“陪跑”，类似于数据中心的热备 2022 年数字时代应用可持续性架构与验证白皮书 21 份。主要用于初期，对于某类型信创设备稳定性信任度较差的阶段。缺点是成本较高，造成大量的资源浪费。并且，这种方式，因为用户侧应用的响应其实还是完全依赖于非信创区，因此不便于将应用侧及信创区设备侧的指标做关联性分析。流量分担：通过加权轮询等方式，赋予信创区较少权重，让其承担少部分业务负载。相比于流量完全复制，其实际承担了部分业务负载，降低了部分成本。故障秒切：通过健康检查，当信创区出现业务故障，秒级切换回传统区，保障业务的可持续性。然后，根据健康检查参数和日志等，找出故障原因，进行恢复。2022 年数字时代应用可持续性架构与验证白皮书 22 平滑过渡：随着信创区稳定性逐步提高，其负载权重也逐步上升，直至占据大部分，甚至全部。协议互通：除了执行节点由传统区逐步过渡到信创区之外，控制/调度节点也应该平滑过渡，这就要求信创的调度、控制节点（负载均衡/应用交付）应与既有设备在协议上保持互通，可直接读取数据。体验一致：除底层协议之外，用户体验层也仍应关注，控制节点的操作体验应尽量与原有设备一致，从而使得客户/用户学习成本最低，迁移平滑。双轨平滑迁移的方式，在早期增大了基础平台层的适配工作量，但将应用和基础设施 2022 年数字时代应用可持续性架构与验证白皮书 23 完全解耦，使得行业客户在迁移时不再拘泥于“一个应用一个应用迁移”这种单一形式，将大幅降低迁移难度，提升迁移进度，并保障了迁移过程中的稳定性。2、多协议支持 应用可持续性，需要在不同层级支持多种主流协议，具体包括：（1）网络层（三层）协议 IPv4：互联网通信协议第 4 版（Internet Protocol version 4），是该协议第一个被广泛部署的版本。IPv4 是互联网的核心，也是目前使用最广泛的互联网通信协议版本。IPv6：互联网通信协议第 6 版（Internet Protocol version 6），是互联网工程任务组（IETF）设计的用于替代 IPv4 的下一代 IP 协议，其地址数量号称可以为全世界的每一粒沙子编上一个地址。IPv6 可避免必须经过多层路由和分发才能到达终端设备，是物联网快速发展的基础保障之一。（2）传输层（四层）协议 UDP：Internet 协议集的无连接的传输协议，该协议称为用户数据报协议（User Datagram Protocol）。UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法。HTTP3/QUIC 协议，其传输层即是采用了 UDP 协议，避免了 TCP 协议头部拥塞问题。TCP：Internet 协议集的面向连接的、可靠的、基于字节流的传输协议，该协议称为传输控制协议（Transmission Control Protocol）。TCP 由 IETF 的 RFC 793 定义。TCP协议在应用层有着极为广泛的应用，HTTP1、HTTP2、FTP、SMTP、POP3 等，传输层均采用 TCP 协议。Fast TCP：TCP 协议的优化分为单边优化和双边优化，而单边优化又可以分为基于丢包的优化和基于时延的优化。Fast TCP 即属于基于时延的优化，与之类似的，还有Compound TCP。Fast TCP 对 TCP 协议的改善主要是在其流量控制方面作了优化：不修改 TCP 协议内包头(TCP Packet Header)的标准格式，只对 TCP 包头里的 Sequence Number,Window Scaling 等数值作修改，并且优化了流量控制的算法，大大提高了 TCP流量的效率，从而提高了广域网带宽的利用率。Fast TCP 对广域网和无线数据网络上的TCP 流量有显著的优化效果,特别在高时延，高丢包率的 TCP 网络环境里，可以减少应用的响应时延，提高 TCP 吞吐量和有效流量的速度，提高无线网络和广域网带宽的利用率。2022 年数字时代应用可持续性架构与验证白皮书 24（3）会话层（五层）协议 RPC：远程过程调用协议（Remote Procedure Call）是一个用于建立适当框架的协议。从本质上讲，它使一台机器上的程序能够调用另一台机器上的子程序，而不会意识到它是远程的。RPC 是一种软件通信协议，一个程序可以用来向位于网络上另一台计算机的程序请求服务，而不必了解网络的细节。RPC 被用来像本地系统一样调用远程系统上的其他进程。过程调用有时也被称为函数调用或子程序调用。（4）应用层（七层）协议 HTTP1.1：超文本传输协议-版本 1.1（Hypertext Transfer Protocol Version 1.1）。相比于 1.0 版本，它增加了长连接，也即在连接后并不立即中断 TCP 连接，之后一定时间之内的 HTTP 请求仍然可以复用 TCP 连接，这就避免了多次连接（尤其是 TCP 连接存在多次握手）的问题。在时间上来看，HTTP1.0 诞生（1996 年）不久之后的 1999 年即诞生，至今仍为全部浏览器及基于 HTTP 协议的应用支持（即使支持 HTTP3 的应用，因普及率问题，在首次请求中也使用 1.1，在响应头中给出自己支持 HTTP3 的说明，以便浏览器等在下次请求时直接使用）。HTTP2:超文本传输协议-版本 2.0（Hypertext Transfer Protocol Version 2.0）。HTTP2 标准于 2015 年 5 月以 RFC 7540 正式发表。相比于 HTTP1.1，主要有如下改进：（1）不再使用文本协议而使用二进制协议传输数据，解析效率更高。（2）多路复用，即多个 HTTP 请求可直接使用同一个 HTTP。如果说 HTTP1.1 实现了在时间的纵向上实现了TCP 连接的复用（长连接），那么 HTTP2.0 就是在同一时间节点的横向上实现了 TCP 连接的复用。（3）头部压缩，在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送。HTTP3：超文本传输协议-版本 3.0（Hypertext Transfer Protocol Version 3.0）。HTTP3 起源于谷歌，原名为 HTTP over QUIC，而 QUIC 意为 QUICk UDP Internet Connections，可见其传输层不再基于 TCP，而是基于 UDP。在前文四层协议部分我们已知，UDP 为无连接直接传输的协议，其可靠性较差，于是 HTTP3 的 QUIC 层对 UDP 进行了大量改进，加入了 TCP-like 可靠特性，并提供与 TLS/SSL 相当的安全性。HTTP3 在经历了长达 6 年，34 个 Draft 版本后，最终在 2022 年 6 月以 RFC9114 发表。由于其终稿确定时间较晚，且牵涉传输层变化，因此当前不少路由和七层负载均衡设备还未能完全支持，但不少互联网厂商在其后期的 Draft 版本时就已经在做自己的开源实现。HTTP3 相比与 HTTP2 有诸多改进，其中比较重要的有：（1）因使用 UDP，彻底解决了 TCP 的头部阻塞问题。（2）不再使用四元组（源 IP、源端口、目的 IP、目的端口）来标识一条连接，2022 年数字时代应用可持续性架构与验证白皮书 25 而使用 Connection ID，也就是其长连接更加稳定，不受用户侧网络环境以及基础设施侧Pod 的变化影响，这在 5G、自动驾驶等频繁更换 IP 甚至网络环境的场景中将发挥重要作用。（3）TLS 单次握手，时延更短。2022 年数字时代应用可持续性架构与验证白皮书 26 FastHTTP：FastHTTP 是 基于 Go 语言 的一款不同于标准库 net/http 的 HTTP 实现，可实现服务器/客户端每秒处理上千个中小型请求，并且要求一致的毫秒级响应时间。3、与现代高可用架构无缝对接 我们可把 IT 架构分为四个阶段：第一个阶段为小型机，其特点是单点高可用，但设备昂贵、封闭，扩展能力有限。第二阶段为硬负载设备 X86 服务器，其特点是依赖硬负载，实现了单服务器节点的容错，通过冗余保障了高可用，同时扩展方便，但负载本身定制性较差。第三阶段为以 NGINX、LVS、HAProxy 为代表的软负载 物理机/虚机，特点是开源、定制性强。第四阶段是以 Kubernetes 为代表的云原生架构，其内部负载一般采用Kubernetes 原生功能，或使用 NGINX、Traefik、Envoy 等。其中，第三和第四阶段，因为符合软件定义基础设施的特点，均可视为现代架构。但在金融等行业中，存在大量的 IT历史包袱，四个阶段的架构和产品均在使用，因此，应用交付系统必须既能利旧，又能面向未来。具体的，应在纵向上，同时跨以下几个环节，实现对接：（1）全局负载均衡（GSLB）为了解决多区域数据中心流量分配而设置的负载均衡，一般有两种实现方式：基于DNS 和基于 HTTP(S)，其中后者主要解决 DNS 逐级递归解析过程中的劫持问题。（2）四层负载均衡 也被称为网络负载均衡，仅用于对 TCP、UDP 流量进行处理。四层负载均衡在转发中主要基于 IP 地址、端口等信息。四层负载均衡的开源软件包括 LVS、DPVS 等。NGINX和 HAProxy 也可用作四层负载，但一般不常用。（3）七层负载均衡 也被称为应用负载均衡，支持 HTTP、HTTPS、SSL（Secure Sockets Layer，安全套接层协议层）、TLS 等协议的处理。七层负载均衡在转发中可以利用应用层的信息，如 HTTP 的请求头，而这些信息对四层负载均衡来说是不可见的。七层负载均衡的开源软件包括 NGINX、HAProxy、BFE、Traefik、Envoy 等。（4）kubernetes Ingress Controller Kubernetes 环境的专用负载均衡器，其作用如下：接受来自 Kubernetes 平台外部的流量，并将其负载均衡到平台内运行的 Pod；管理集群内的出口流量，用于需要与集群外的其他服务通信的服务；使用 Kubernetes API 进行配置，以部署名为“入口资源”的对象；监控 Kubernetes 中运行的 Pod，并在服务中添加或删除 Pod 时自动更新负载均衡规则。Kubernetes IngressController 的对应方案有 NGINX 和 Traefik 等。2022 年数字时代应用可持续性架构与验证白皮书 27 未来，Ingress 有可能被更具有扩展性的 Kubernetes Gateway API 取代，但目前其仍处于 Alpha 阶段。4、可观测性和分析 可观测性是伴随云原生而诞生的概念，但其实监测、日志和追踪在传统架构中都存在已久。之所以在云原生时代将可观测性提升到一个更加重要的地位，是因为云主机一台主机上应用程序的部署密度和变化频率较传统环境都更高，因此，需要可观测性来清晰地发现和记录主机快速变化的行为。另外，应用架构的微服务化使应用之间的访问关系变得异常复杂，客户端的一次服务请求通常会产生包括服务和中间件在内的众多调用关系。清晰地观察到这种调用关系，无论是对于应用性能提升、故障定位还是安全检测，都有着重要的意义。（1）可观测性实现手段 日志：展现的是应用程序运行产生的事件或记录，可以详细解释其运行状态。日志描述了一些离散的、不连续的事件，对于应用程序的可见性是很好的信息来源，也为应用程序的分析提供了精确的数据源。日志的数据量较大，但价值密度较低，一般有两种使用方 2022 年数字时代应用可持续性架构与验证白皮书 28 式：事后进行定位分析。依赖于指标，进行迅速抽取、聚合，并实时分析。指标：与日志有所不同，日志提供的是显式数据，而指标是通过数据的聚合，对一个程序在特定时间内的行为进行衡量。指标数据是可累加的，它们具有原子性，每个都是一个逻辑计量单元。指标数据可以观察系统的状态和趋势，但对于问题定位缺乏细节展示。追踪：面向的是请求，可以分析出请求中的异常点，但与日志有相同的资源消耗问题，通常需要通过采样等方式减少数据量。追踪的最大特点是它在单次请求的范围内处理信息，任何数据、元数据信息都被绑定到系统中的单个事务上。在 CNCF 给出的云原生全景图中，将可观测性和分析放在了同一个维度。一方面通过实现可观测性的工具，获取系统中各个维度的运行数据，从而对整个云原生架构下的应用运行情况有全面深入的了解；另一方面，在拥有了这些数据之后，可以进行安全性分析、运维故障分析、性能分析等。另外，这些数据一般也会输出到包括应用交付系统中，以提供动态负载、智能决策等。2（2）具体观测内容 资源层监测：高权重指标包括 CPU 使用率、GPU 使用率、内存使用率、磁盘使用率、集群节点总数、Node 使用、集群中调度完成 Pod 数、当前进程打开文件数。中权重指标包括集群中处于 Succeeded 阶段的 Pod 数、集群中处于 Running 阶段的 Pod 数、当前内核空间占 CPU 百分比、磁盘每秒写入字节数、GPU 显存空间量、过去 2 刘文懋，江国龙，浦明作.云原生安全 攻防实践与体系构建M.北京：机械工业出版社,2021.10.2022 年数字时代应用可持续性架构与验证白皮书 29 五分钟系统平均负载。低权重指标包括调度器调度频率、集群 Job 数、集群 Secret 数、调度器在线实例数、当前用户空间占用 CPU 百分比、集群 Namespace 数、集群Endpoint 数。网络监测：高权重指标主要包括客户链接数、丢包率、流量、吞吐量、客户端延时、事件连接数、建连成功率。中权重指标主要包括流出包数、网络评分、流出字节、服务器延时、包大小分布、建连成功率。低权重指标主要包括带宽、流入吞吐量、大包占比、重传时延、流入字节、流出吞吐量、中包占比、0 窗口。中间件监测：高权重指标主要包括消息订阅详情、消息阅读量、消息推送平均耗时、消息订阅平均耗时、消息推送详情、消息推送数量。中权重指标包括 Young GC 平均数量、Eden 平均使用情况、Full GC 平均是量、老年代使用率、Eden 使用率、Young GC平均时间、Full GC 平均时间。低权重指标包括 OSS 请求数量、OSS 请求平均耗时。数据库监测：高权重指标包括查询响应时间、查询错误率、QPS、连接数、连接数利用率、健康度。中权重指标包括数据库请求数、数据库请求平均耗时、SQL 查询耗时排名、数据库请求详情。低权重指标主要包括 Tair 内存数据库请求数、Tair 请求详情、Tair 请求平均耗时。应用（Server 侧）监测：高权重指标主要包括健康度、Apdex、吞吐率、响应时间、错误率。中权重指标主要包括慢请求次数、调用数据库错误率、慢请求占比、调用数据库次数、调用 MQ 次数、调用数据库响应时间。低权重指标主要包括调用外部服务次数、调用外部服务响应时间、调用外部服务错误率、调用 MQ 错误率。用户（Client 侧）监测：高权重指标主要包括可优化延时、体验评分、首屏时间、ANR、卡顿、整体性能、崩溃、可用性、白屏时间、通过率、可交互时间、首次渲染时间。中权重指标主要包括活跃用户数、JS 错误、请求错误率、请求错误、劫持比例、DNS时间。低权重指标主要包括 400 错误率、ping 耗时、SSL 建连时间、响应时间、500错误率、TCP 建连时间、信息量、设备型号、600 错误率、CDN 城市匹配率、CDN 运营商匹配、CDN 请求性能、应用安装耗时、首包时间。2022 年数字时代应用可持续性架构与验证白皮书 30 5、负载可编排 如果把可观测比作感知神经，那么负载就是运动神经。它可将可观测系统的输出，直接转为自己的输入，进而动态调整，保障应用的可持续性。（1）静态算法 静态算法中，下游节点业务负载占比是固定不变的，也即负载设备不根据可观测系统监测到的下游节点的性能指标进行动态调整。轮询：最简单的调度算法，LB 按照顺序将请求一次性转发给后端的真实服务器（RS），并不参考后端 RS 的处理能力和响应速度。但是在大多数的真实环境中，RS 的状态各不相同，这种算法无法满足合理利用资源的要求。轮询是最基础的算法，一般在对负载设备本身利用 jmeter 等进行压力测试时，轮询是必测项。加权轮询：带权重的轮询是在轮询算法的基础上为后端 RS 赋予权重值，权重值越高的 RS 被分配的请求越多，这种方式适合按照服务器性能的高低赋予不同的权重值，从而达到合理的资源利用。随机：不考虑服务器权重，每个服务器会被随机的访问到，由概率论可以得知，当样本量足够大时，每台服务器被访问到的几率近似是相等的，随机算法的效果就越趋近于轮询算法。目标 IP 哈希：该算法是一种静态映射算法，针对请求报文的目的 IP，通过一个哈希函数将一个目的 IP 映射到一台服务器。DH 算法将请求的目的 IP 作为 Hash Key 并从静态分配的散列表中找出对应的服务器。如果该服务器是可用的并且没有超载，则将请求发送给该服务器，否则返回空。源 IP 哈希：SH 算法与 DH 算法相反，它根据请求中的源 IP 地址作为 Hash Key 并从静态分配的散列表中找出对应的服务器。如果该服务器是可用的并且没有超载，则将请求发送给该服务器，否则返回空。2022 年数字时代应用可持续性架构与验证白皮书 31 URL 哈希：该算法按访问 URL 的 Hash 结果来分配请求，使每个 URL 定向到一个后端服务器，后端服务器有缓存功能时，可以有效地提升处理能力。（2）基础动态算法 动态负载中，可观测系统，将各种监测指标实时反馈给负载均衡，负载均衡根据这些指标，实时对下游节点间权重做出调整。最少连接：该算法会将请求分发到连接数最少的 RS 上，连接数越少，说明 RS 相对空闲，从而实现均衡的负载。加权最少连接：该算法在采用最少连接数的同时为 RS 分配权重，目的是在资源实际使用的基础上，达到人为控制连接请求的分配。基于局部性的最少连接：这是一种基于报文目的 IP 的负载均衡调度方式，常用于Cache 集群系统。Cache 集群中客户请求报文的目的 IP 地址是变化的，目的是将相同目的 IP 的请求调度到同一台 RS 上响应，以便提高每台 RS 的访问局部性和主存 Cache 的命中率，从而提升整个集群的处理能力。该算法根据请求的目的 IP 地址首先找出该目的 IP地址最近使用的服务器，若该服务器是可用的且没有超载，会将请求发送到该服务器；若服务器不存在，或者该服务器超载且有其他服务器处于较低的工作负载状态，则用“最少连接”原则选出一个可用的服务器，将请求发送到该服务器。带复制的基于局部性最少连接：与 LBLC 场景相同，常用于 Cache 集群系统。但是LBLC 是维护一个目的 IP 到一台服务器的映射，而 LBLCR 算法是用于维护一个目的 IP 到一组服务器的映射。即，根据请求的目标 IP 找出对应的服务器组，按“最少连接”原则从服务器组中选出一台服务器来响应，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个 Cache 集群中选出一台服务器，将该服务器加入到服务器组中，再将请求发送到该服务器。3 Fair 调度算法：该算法按照后端服务器的响应时间来分配请求，响应时间越短越优先分配。（3）动态算法扩展 除常见动态算法外，还可以自定义动态负载均衡算法，目前，在学术界，已经对遗传算法、领导者选举算法、布谷鸟搜索算法等在负载均衡中进行尝试，甚至将基于深度学习的流量预测用于负载均衡，但在生产中，这些应用仍较少。动态负载均衡算法扩展应考虑以下要素：（1）可观测系统的监测指标及其权重。（2）监测指标的离散程度：如节点的CPU 利用较高，但磁盘利用较低，实际上已经产生资源碎片，并非单依靠负载均衡能解决。3 方国伟著.企业云计算 原理、架构与实践指南M.北京：清华大学出版社,2020.01.2022 年数字时代应用可持续性架构与验证白皮书 32（3）算法本身的可靠性：在局部更优的算法有可能因过拟合，在更广泛的场景中性能较差。（4）算法本身的执行时间和性能损耗：如果将阈值设置较低，可能导致节点间权重频繁切换，产生不必要的性能损耗。6、主动韧性 大多情况下，对于应用可持续性的关注点往往在于被动健壮，也即尽量“想”全所有的问题，但包括混沌工程在内的高可用测试，则直接以“试”的方式让架构实现主动健壮。其类似于“军演”，在对业务完全无影响，或者控制好爆炸半径的情况下，对架构发起计划的或随机的测试，从而使得架构更加稳定、健壮，具备韧性。（1）高可用测试 高可用测试是指测试一个系统或应用程序是否能够维持可接受的可用性水平。这通常包括测试软件系统、硬件系统和网络系统的可靠性和可用性、冗余性和冗余能力、发生故障时的容错能力、以及灵活性和扩展性。高可用测试还可能包括性能测试、安全测试和其他类型的测试，以确保系统能够承受预期的工作负载并且保护数据安全。通常，高可用测试会包括以下几个方面：测试系统的容错能力，即在出现故障时系统能否保持正常运行。测试系统的负载均衡能力，即在高流量状态下系统能否保持正常运行。测试系统的自恢复能力，即在出现故障后系统能否自动恢复正常运行。高可用测试可以帮助评估系统的可靠性和可用性，并为系统的运维和维护提供重要的参考信息。（2）混沌工程 混沌工程是一种软件工程方法，旨在利用混沌系统的特性来提高软件的可靠性和可用性。混沌系统是指在一定条件下，其状态会发生非常不稳定的变化，并且很难预测的系统。混沌工程的基本思想是，通过设计软件系统的架构和运行模式，使其具有混沌系统的特性，从而提高系统的可靠性和可用性。例如，通过设计系统的分布式架构，使得系统在出现故障时能够自动进行故障转移，从而保证系统的正常运行。混沌工程主要用于对大型、复杂的系统进行开发，常见的应用场景包括金融、医疗和电信等领域。它可以通过模拟不同的故障情况来评估系统的容错能力，并通过对软件的改进来提高系统的可靠性和可用性。混沌工程常见的技术包括混沌测试、混沌设计和混沌监控等。混沌工程属于高可用测试的一种，但与传统的高可用测试又有明显区别，其中最大区 2022 年数字时代应用可持续性架构与验证白皮书 33 别在于传统高可用测试往往是验证已知，即使结果未知但故障已知，而混沌工程往往是发现未知。7、开放与集成 在开放性与集成性方面，应用可持续性产品应支持 CLI、API 和 GUI 等不同方式的操作，以真正实现基础设施即代码（IaC）。（1）GUI：用户图形接口。目前一般为 BS 架构，也即支持 H5 的交互式操作、移动端可自适应。语言应支持多国语言，至少支持中英双语。（2）API：应用程序接口。一般指通过 HTTP 协议传输的，以 Json 为请求体和响应体的 Restful API，未来还包括 GraphQL 风格的 API。API 可摆脱数据、应用对接中对特定开发语言的限制。为了安全起见，API 调用前一般还须进行鉴权，包括静态 Appkey、动态 Sign 以及 OAuth2.0 认证等。（3）CLI：命令行接口。尽管 GUI 更易理解，学习成本更低，但命令行仍在多场景下发挥作用，其资源开支更小，也更容易实现标准化与批量化，尤其在 linux 的开发和运维中，仍十分常见。2022 年数字时代应用可持续性架构与验证白皮书 34 第四章 应用可持续性架构验证指标体系 根据应用可持续性架构的整体设计思想和细分特征，结合金融、运营商、能源、政务等多个行业对应用可持续性架构的关注点，我们总结出了 4 类 37 个通用指标，并给出了常规测试步骤。具体企业在实际测试时，可根据自身情况，对具体指标进行调整。一、性能测试 1、四层吞吐性能测试 测评目标：四层流量吞吐最佳性能。功能说明及应用场景描述：验证 IPv4/IPv6 环境下负载均衡设备四层吞吐的最佳性能。测试步骤：（1）负载均衡器工作正常，使用单臂组网进行测试；（2）配置负载均衡器工作在四层模式，并且进行如下配置：-配置一个 VS；-负载均衡算法：轮询法；-健康检查算法：ICMP，周期为 3 秒；-会话保持：不开启；-负载均衡器不能开启缓存及压缩功能；（3）配置测试仪表、仪表仿真后台服务器：-配置仿真后台服务器数量为 16 个，工作正常；-均可提供 HTTP 服务，并确认可以回应 ICMP 包；-页面内容采用 256K Byte 的静态文本页面测试；（4）仪表仿真客户端：-仪表仿真的源 IP 地址，IP 地址数量 200；-每一个 connection 中只有一个 transaction，即只有一个 get；（5）配置测试仪表，使其仿真的 Server 在收到 HTTP request 后，立即响应；（6）配置测试仪表，使其仿真的 HTTP 页面如预置条件所述；（7）测试负载均衡器吞吐量（Goodput）的最大值（稳定值，瞬时峰值无效），达到最大压力后保持压力 5 分钟，记录最大吞吐能力 Goodput 的测试值(业务成功率必须大于 98%，记录的最大吞吐能力 Goodput 为双向流量之和，但其中不包含由于重传引起的流量)；2022 年数字时代应用可持续性架构与验证白皮书 35（8）分别验证 IPv4 和 IPv6 两种场景。2、四层新建速率性能测试 测评目标：四层 TCP 新建速率最佳性能。功能说明及应用场景描述：验证 IPv4/IPv6 环境下负载均衡设备四层新建的最佳性能。测试步骤：（1）负载均衡器工作正常，使用单臂组网进行测试；（2）配置负载均衡器工作在四层模式，并且进行如下配置：-配置一个 VS；-负载均衡算法：轮询法；-健康检查算法：ICMP，周期为 3 秒；-会话保持：不开启；-负载均衡器不能开启缓存及压缩功能；（3）配置测试仪表、仪表仿真后台服务器：-配置仿真后台服务器数量为 16 个，工作正常；-均可提供 HTTP 服务，并确认可以回应 ICMP 包；-页面内容采用 64Byte 的静态文本页面测试；（4）仪表仿真客户端：-仪表仿真的源 IP 地址，IP 地址数量 200；-每一个 connection 中只有一个 transaction，即只有一个 get；（5）配置测试仪表，使其仿真的 Server 在收到 HTTP request 后，立即响应；（6）配置测试仪表，使其仿真的 HTTP 页面如预置条件所述；（7）测试负载均衡器新建的最大值（稳定值，瞬时峰值无效），达到最大压力后保持压力 5 分钟，记录最大新建的测试值(业务成功率必须大于 98%)；（8）分别验证 IPv4 和 IPv6 两种场景。3、四层并发性能测试 测评目标：四层并发连接数最佳性能。功能说明及应用场景描述：验证 IPv4/IPv6 环境下负载均衡设备四层并发的最佳性能。测试步骤：（1）负载均衡器工作正常，使用单臂组网进行测试；（2）配置负载均衡器工作在四层模式，并且进行如下配置：2022 年数字时代应用可持续性架构与验证白皮书 36-配置一个 VS；-负载均衡算法：轮询法；-健康检查算法：ICMP，周期为 3 秒；-会话保持：不开启；-负载均衡器不能开启缓存及压缩功能；（3）配置测试仪表、仪表仿真后台服务器：-配置仿真后台服务器数量为 16 个，工作正常；-均可提供 HTTP 服务，并确认可以回应 ICMP 包；-页面内容采用 64Byte 的静态文本页面测试；（4）仪表仿真客户端：-仪表仿真的源 IP 地址，IP 地址数量大于 2000；-每一个 connection 中只有一个 transaction，即只有一个 get；（5）配置测试仪表，使其仿真的 Server 在收到 HTTP request 后，立即响应；（6）配置测试仪表，使其仿真的 HTTP 页面如预置条件所述；（7）测试负载均衡器并发的最大值（稳定值，瞬时峰值无效），达到最大压力后保持压力 5 分钟，记录最大并发的测试值(业务成功率必须大于 98%)；（8）分别验证 IPv4 和 IPv6 两种场景。4、七层吞吐性能测试 测评目标：七层流量吞吐最佳性能。功能说明及应用场景描述：验证 IPv4/IPv6 环境下负载均衡设备七层吞吐的最佳性能。测试步骤：（1）负载均衡器工作正常，使用单臂组网进行测试；（2）配置负载均衡器，使负载均衡器工作在七层模式，并且进行如下配置：-配置一个 VIP；-配置四个服务器组，每个服务器组均包含 4 台服务器，总共 16 台服务器；-负载均衡算法：基于 URL 内容的负载均衡算法：将 URL 包含“sports、news、government”的请求分给服务器组1，服务器组 1 的服务器之间采用轮询负载均衡算法；将 URL 包含“finance、technology、shopping”的请求分给服务 2022 年数字时代应用可持续性架构与验证白皮书 37 器组 2，服务器组 2 的服务器之间采用 1:1:1 的比重负载均衡算法；将 URL 包含“game、bbs、testing”的请求分给服务器组 3，服务器组 3 的服务器之间采用轮询负载均衡算法；将 URL 包含“billing、travel、weibo”的请求分给服务器组 4，服务器组 4 的服务器之间采用 1:1:1 的比重负载均衡算法；对于未能匹配上述 URL 内容的连接，则按照最少连接负载均衡法分配给后台 16 台服务器：健康检查算法：ICMP，周期为 3 秒；负载均衡器不能开启 Cache 功能、压缩功能；（3）仪表仿真后台服务器：-数量为 16，工作正常；-均可提供 HTTP 服务，并确认可以回应 ICMP 包；-页面内容为 256K Byte 的静态文本页面；（4）仪表仿真客户端：-仪表仿真的源 IP 地址数量 200；-客户端的 Think time 均为 0；-每一个 connection 中包含上述列表中所有 transaction，即多个 get；（5）配置测试仪表，使其仿真的 Server 在收到 HTTP request 后，立即响应；（6）配置测试仪表，使其仿真的 HTTP 页面如预置条件所述；（7）客户端的配置如下：-每个客户端的 Action List 都含有如下指令：1 get http:/vip/sports 1 get http:/vip/news 1 get http:/vip/government 1 get http:/vip/finance 1 get http:/vip/technology 1 get http:/vip/shopping 1 get http:/vip/game 1 get http:/vip/bbs 1 get http:/vip/testing 1 get http:/vip/billing 2022 年数字时代应用可持续性架构与验证白皮书 38 1 get http:/vip/travel 1 get http:/vip/weibo 1 get http:/vip/xxxxx（x 可以是不匹配上述 URL 的任意值）-客户端之间的上述 Action List 的顺序可以不同，防止后台服务器的拥塞；（8）测试负载均衡器吞吐量（Goodput）的最大值（稳定值，瞬时峰值无效），达到最大压力后保持压力 5 分钟；记录最大吞吐能力 Goodput 的测试值(业务成功率必须大于98%,记录的最大吞吐能力 Goodput 为双向流量之和，但其中不包含由于重传引起的流量)；（9）分别验证 IPv4 和 IPv6 两种场景。5、七层新建事务速率性能测试 测评目标：七层请求事务速率最佳性能。功能说明及应用场景描述：验证 IPv4/IPv6 环境下负载均衡设备七层新建事务数的最佳性能。测试步骤：（1）负载均衡器工作正常，使用单臂组网进行测试；（2）配置负载均衡器，使负载均衡器工作在七层模式，并且进行如下配置：-配置一个 VIP；-配置四个服务器组，每个服务器组均包含 4 台服务器，总共 16 台服务器；-负载均衡算法：基于 URL 内容的负载均衡算法：将 URL 包含“sports、news、government”的请求分给服务器组1，服务器组 1 的服务器之间采用轮询负载均衡算法；将 URL 包含“finance、technology、shopping”的请求分给服务器组 2，服务器组 2 的服务器之间采用 1:1:1 的比重负载均衡算法；将 URL 包含“game、bbs、testing”的请求分给服务器组 3，服务器组 3 的服务器之间采用轮询负载均衡算法；将 URL 包含“billing、travel、weibo”的请求分给服务器组 4，服务器组 4 的服务器之间采用 1:1:1 的比重负载均衡算法；对于未能匹配上述 URL 内容的连接，则按照最少连接负载均衡法分配给后台 16 台服务器：健康检查算法：ICMP，周期为 3 秒；2022 年数字时代应用可持续性架构与验证白皮书 39 负载均衡器不能开启 Cache 功能、压缩功能；（3）仪表仿真后台服务器：-数量为 16，工作正常；-均可提供 HTTP 服务，并确认可以回应 ICMP 包；-页面内容为 64Byte 的静态文本页面；（4）仪表仿真客户端：-仪表仿真的源 IP 地址数量 200；-客户端的 Think time 均为 0；-每一个 connection 中包含上述列表中所有 transaction，即多个 get；（5）配置测试仪表，使其仿真的 Server 在收到 HTTP request 后，立即响应；（6）配置测试仪表，使其仿真的 HTTP 页面如预置条件所述；（7）客户端的配置如下：-每个客户端的 Action List 都含有如下指令：1 get http:/vip/sports 1 get http:/vip/news 1 get http:/vip/government 1 get http:/vip/finance 1 get http:/vip/technology 1 get http:/vip/shopping 1 get http:/vip/game 1 get http:/vip/bbs 1 get http:/vip/testing 1 get http:/vip/billing 1 get http:/vip/travel 1 get http:/vip/weibo 1 get http:/vip/xxxxx（x 可以是不匹配上述 URL 的任意值）-客户端之间的上述 Action List 的顺序可以不同，防止后台服务器的拥塞；（8）测试负载均衡器每秒新建事务的最大值（稳定值，瞬时峰值无效），达到最大压力后保持压力 5 分钟；记录每秒新建会话（RPS）连接数的测试值(业务成功率必须大于98%)；（9）分别验证 IPv4 和 IPv6 两种场景。2022 年数字时代应用可持续性架构与验证白皮书 40 6、七层并发性能测试 测评目标：七层并发连接数最佳性能。功能说明及应用场景描述：验证 IPv4/IPv6 环境下负载均衡设备七层并发连接会话的最佳性能。测试步骤：（1）负载均衡器工作正常，使用单臂组网进行测试；（2）配置负载均衡器，使负载均衡器工作在七层模式，并且进行如下配置：-配置一个 VIP；-配置四个服务器组，每个服务器组均包含 4 台服务器，总共 16 台服务器；-负载均衡算法：基于 URL 内容的负载均衡算法：将 URL 包含“sports、news、government”的请求分给服务器组1，服务器组 1 的服务器之间采用轮询负载均衡算法；将 URL 包含“finance、technology、shopping”的请求分给服务器组 2，服务器组 2 的服务器之间采用 1:1:1 的比重负载均衡算法；将 URL 包含“game、bbs、testing”的请求分给服务器组 3，服务器组 3 的服务器之间采用轮询负载均衡算法；将 URL 包含“billing、travel、weibo”的请求分给服务器组 4，服务器组 4 的服务器之间采用 1:1:1 的比重负载均衡算法；对于未能匹配上述 URL 内容的连接，则按照最少连接负载均衡法分配给后台 16 台服务器：健康检查算法：ICMP，周期为 3 秒；负载均衡器不能开启 Cache 功能、压缩功能；（3）仪表仿真后台服务器：-数量为 16，工作正常；-均可提供 HTTP 服务，并确认可以回应 ICMP 包；-页面内容为 64Byte 的静态文本页面；（4）仪表仿真客户端：-仪表仿真的源 IP 地址数量大于 2000；-每一个 connection 中包含上述列表中所有 transaction，即多个 get；2022 年数字时代应用可持续性架构与验证白皮书 41（5）配置测试仪表，使其仿真的 HTTP 页面如预置条件所述；（6）客户端的配置如下：-每个客户端的 Action List 都含有如下指令：1 get http:/vip/sports 1 get http:/vip/news 1 get http:/vip/government 1 get http:/vip/finance 1 get http:/vip/technology 1 get http:/vip/shopping 1 get http:/vip/game 1 get http:/vip/bbs 1 get http:/vip/testing 1 get http:/vip/billing 1 get http:/vip/travel 1 get http:/vip/weibo 1 get http:/vip/xxxxx（x 可以是不匹配上述 URL 的任意值）-客户端之间的上述 Action List 的顺序可以不同，防止后台服务器的拥塞；（7）测试负载均衡器连接数的最大值（稳定值，瞬时峰值无效），达到最大压力后保持压力 5 分钟；记录最大连接会话的测试值(业务成功率必须大于 98%)；（8）分别验证 IPv4 和 IPv6 两种场景。二、基础功能测试 1、网络端口聚合功能 测评目标：验证设备是否支持网络端口聚合功能。功能说明及应用场景描述：网络端口聚合可以增强网络端口带宽和冗余性，是负载均衡设备部署时经常使用的技术。（1）支持 LACP 主被动模式设置；（2）应与交换机支持静态和动态两种模式的端口聚合。测试步骤：（1）负载均衡设备和交换机互联多个网络端口采用动态模式聚合捆绑，负载均衡设备 2022 年数字时代应用可持续性架构与验证白皮书 42 聚合端口的 LACP 模式设置为主动模式。验证网络端口聚合后通讯是否正常；（2）中断聚合端口中的一条网络线路，验证通讯是否正常；（3）聚合端口添加一个网络端口和删除一个网络端口通讯是否正常；（4）负载均衡设备聚合端口的 LACP 模式设置为被动模式，交换机配置聚合端口组为动态聚合类型，在交换机上抓包查看 LACP 协商结果；（5）设置负载均衡设备网络端口采用静态模式聚合捆绑，静态算法应支持 balance-rr/active-bakup/balance-xor/broadcast/balance-tlb/balance-alb 等。验证静态算法的聚合端口通信是否正常。预期结果：（1）负载均衡设备支持动态链路聚合技术；（2）聚合端口的某线路中断不影响正常通讯；（3）添加和删除聚合端口的某网络端口成员也不影响正常通讯；（4）负载均衡设备支持 LACP 主动或被动，负载均衡设备与交换机能够正常协商、流量正常发送和接受；（5）负载均衡设备支持静态模式的端口聚合。2、基本负载均衡算法(IPv4/IPv6 双栈）测评目标：验证基本负载均衡算法。功能说明及应用场景描述：负载均衡算法是 SLB 虚拟服务器调度应用请求的策略依据。基本的调度算法应支持轮询、最小连接数、权重比例和优先级算法等（支持指定某一优先级组内的服务器数量少于预设的阈值时即启用新的优先级组）。测试步骤：（1）负载均衡算法选择轮询算法，确认后台服务器是否按照预定的算法进行分配连接；（2）负载均衡算法选择最小连接数算法，确认后台服务器是否按照预定的算法进行分配连接；（3）负载均衡算法选择权重比例算法，确认后台服务器是否按照预定的算法进行分配连接；（4）启用优先级组，设置服务器数量阈值，确认后台服务器是否按照预定的算法进行分配连接。预期结果：支持轮询、最小连接数和权重比例和优先级负载均衡算法。2022 年数字时代应用可持续性架构与验证白皮书 43 3、Virtual Server 功能 测评目标：验证 Virtual Server 各项功能是否正常。功能说明及应用场景：（1）引用四层策略的四层 VS 工作正常，并且外部设备对这些 VS 进行探测时，响应探测的是 RS 地址；（2）引用七层策略的七层 VS 工作正常，并且外部设备对这些 VS 进行探测时，响应探测结果的是 VS 地址；（3）四层策略支持 TCP、UDP 协议，并且可以对连接参数进行设置，例如：空闲超时时间等参数（即并发连接超过预设值之后由负载均衡进行代应答 SYN 包）进行个性化设置；（4）七层策略支持 FTP、HTTP1.1、HTTP2.0 协议；（5）支持 FTP 协议的 VS，并且可以自动识别 FTP 主被动模式，正常进行转发；（6）配置 VS 验证 IPv4/IPv6 双栈转换是否正常，并且验证应用池成员同时存在 IPv4和 IPv6 混合场景是否可以正常工作。测试步骤：（1）验证设备是否支持配置四层的 VS；（2）验证设备是否支持配置七层类型的 VS；（3）验证四层策略支持 TCP、UDP 协议，并且可以对连接参数进行设置；（4）验证七层策略支持 FTP、HTTP1.1、HTTP2.0 协议，并且 FTP 必须支持主被动模式自动识别。预期结果：（1）引用四层策略的四层 VS 工作正常，并且外部设备对这些 VS 进行探测时，响应探测的是 RS 地址；（2）引用七层策略的七层 VS 工作正常，并且外部设备对这些 VS 进行探测时，响应探测结果的是 VS 地址；（3）四层策略支持 TCP、UDP 协议，并且可以对连接参数进行设置，例如：空闲超时时间等参数（即并发连接超过预设值之后由负载均衡进行代应答 SYN 包）进行个性化设置；（4）七层策略支持 FTP、HTTP1.1、HTTP2.0 协议。并且 FTP 必须支持主被动模式自动识别。2022 年数字时代应用可持续性架构与验证白皮书 44 4、健康检查基本功能(IPv4/IPv6 双栈）测评目标：健康检查基本功能测试(IPv4/IPv6 双栈）。功能说明及应用场景：健康检查是 SLB 应用场景中最重要的基础技术之一，通过它来检测应用服务器运行是否正常。虚拟服务器在流量调度时依据应用池成员的健康状态，始终将应用流量转发给运行正常的应用服务器。为了更加准确的检测到应用服务器健康状态，负载均衡设备应该具备丰富的健康检查手段，包括：（1）基本的健康检查方法包括：ICMP、TCP、TCP 半连接、UDP、HTTP、HTTPs等类型；（2）支持深度定制的健康检查方法，包括：HTTP2.0 健康检查、数据库查询健康检查、主从数据库状态的健康检查、定制 TCP 携带指定字符串健康检查等；（3）针对深度定制的脚本化健康检查方法，应该可以通过 Web 管理界面方面查看和编辑脚本（Perl 或 Python 等）。测试步骤：（1）创建健康检查，健康检查类型分别选择 ICMP、TCP、TCP 半连接、UDP、HTTP 和 HTTPs，探测的频次和时间进行自定义配置。同时验证健康检查机制是否生效；（2）创建 TCP Socket 脚本类型健康检查，在 TCP 报文中携带指定字符串，验证是否可以收到约定返回值。如果返回值符合预期则认为应用服务器运行正常，否则判定健康状态异常；（3）创建 HTTP2.0 脚本类型健康检查，负载均衡设备将使用 HTTP2.0 协议检测应用服务器；（4）创建数据库查询脚本类型健康检查，通过管理界面调整数据库查询指令，验证是否可以收到约定的返回值。如果返回值符合预期则认为数据库服务器运行正常，否则判定健康状态异常；（5）创建判断主从数据库状态的脚本类型健康检查，根据数据库主从状态判断应用服务器健康状态；（6）以上脚本类型健康检查方法，可以通过 Web 管理界面进行查询和修改操作；（7）应用池中绑定对应的健康检查，查看应用池中成员的健康检查状态，抓包查看负载均衡设备到应用服务器之间的健康检查数据。预期结果：（1）设备支持 ICMP、TCP、UDP、HTTP、HTTPs 健康检查方法，支持通过健康检 2022 年数字时代应用可持续性架构与验证白皮书 45 查检查到服务器真实状态。当应用服务器故障，健康检查状态为异常（down）。当应用服务器工作正常，健康检查状态为正常（up）；（2）支持 TCP Socket 深度健康检查，TCP 请求携带指定字符串，收到约定的返回值则认为健康状态正常；（3）支持 HTTP2.0 协议的健康检查；（4）支持数据库的深度健康检查，发送数据库查询指令，收到约定的返回值认为正常，否则异常；（5）支持数据库的深度健康检查，可以判断数据库的主从状态，只有主机状态的数据库服务器健康状态正常；（6）Web 管理界面下支持配置/查看/编辑脚本（Perl 或 Python 等）的健康检查。5、SNAT 池基本功能 测评目标：验证 SNAT 池是否支持多种源地址分配策略。功能说明及应用场景：系统具备 SNAT 功能，可以通过 Web 管理界面为虚拟服务器灵活设置 SNAT 规则，适应后端业务网络或应用服务器的不同要求。SNAT 地址可以是一个或多个地址，也可以是 VS 地址。SNAT 地址为多个时，可提供多种分配算法，至少应包括：按 IP 轮询、按端口轮询、最小使用端口和保持源端口等。测试步骤：（1）新建一个 SNAT Pool，添加转换后的源地址池，源地址分配策略选择为“IP 轮询”；（2）新建一个 VS，并关联之前创建的 SNAT Pool，并至于默认的 default 策略前；（3）客户端访问 VS，查看会话连接表，核对数据包过负载之后转换的源地址；（4）更改第一步创建的 SNAT Pool 的源地址分配策略依次选择为“按端口轮询”、“最小使用端口”、“保持源端口”；（5）客户端再次访问 VS，查看会话连接表，核对数据包过负载之后转换的源地址。预期结果：（1）源地址分配策略选择为“IP 轮询”时，源地址会依次轮询转换为 SNAT 地址池里的 IP；（2）源地址分配策略选择为“按端口轮询”时，源地址会转换为 SNAT 地址池里其中一个 IP，只有当这个地址的端口全被占用时，才会转换为 SNAT 地址池里其他 IP；（3）源地址分配策略选择为“最小使用端口”时，源地址会转换为 SNAT 地址池中 2022 年数字时代应用可持续性架构与验证白皮书 46 端口使用最少的 IP；（4）源地址分配策略选择为“保持源端口”时，经过源地址转换以后，客户端的源端口会保持不变。6、Cookie 会话保持功能 测评目标：验证 Cookie 基会话保持功能。功能说明及应用场景：支持 Cookie 会话保持。测试步骤：（1）会话保持模板 SP2，类型为 Cookie insert；（2）虚拟服器分别绑定会话保持模板；（3）客户端访问虚拟服务器查看虚拟服务器运行状态和抓包信息。预期结果：类型为 Cookie insert 的会话保持，请求中携带服务端响应的 Cookie 且Cookie 名称与模板配置一致，请求在会话保持时间内被分配在同一个 RS 上。7、HTTP header 会话保持功能 测评目标：验证设备是否支持 HTTP header 会话保持功能测试。功能说明及应用场景：支持通过 Web 管理界面配置高级会话保持方式，应包括基于HTTP header、URL 和查询参数 args 等会话保持策略。测试步骤：（1）创建载均衡应用池：“应用负载”“应用池”“增加”-创建应用池“调度算法【轮询算法】”-添加真实服务器；（2）虚拟服务器：“应用负载”“虚拟服务器”“增加”“名称【虚拟服务器名称】”“虚拟 IP 及端口【对应的 IP 和端口】-“协议类型【smart-http】”“会话保持模板【本测试用例中创建的会话保持】”-“应用池【本测试用例中创建的应用池】；（3）创建会话保持：-基于主机头 host；-基于 URL；-基于查询参数 args；（4）依次配置负载均衡虚拟服务器会话保持为 host 类型、URL 类型、查询参数args，客户端发起访问并核对访问结果。预期结果：（1）基于主机头 host 的会话保持，host 字段值相同的客户端请求始终转发到相同的 2022 年数字时代应用可持续性架构与验证白皮书 47 真实服务器；（2）基于 URL 的会话保持，URL 值相同的客户端请求始终转发到相同的真实服务器；（3）基于查询参数 args 的会话保持，查询参数值相同的客户端请求始终转发到相同的真实服务器。8、源地址插入和提取功能 测评目标：验证设备是否支持通过 TCP option 或 payload 插入客户端 IP。功能说明及应用场景：（1）支持 TCP option 或 payload 插入客户端 IP 信息，可通过 Web 管理界面进行配置；（2）TCP option 插入源地址的同时，还可以自定义插入前缀信息，例如声明插入的源地址版本是 IPv4 还是 IPv6。测试步骤：（1）通过 TCP option 插入客户端 IP 信息：-创建负载均衡应用池和虚拟服务器；-开启客户端地址携带：“应用负载”“配置模板”“TCP&UDP 模板”：找到“客户端 IP 地址携带(TCP option)”，点击启用；-客户端发起访问，并在负载或者真实服务器上抓包；（2）通过 payload 插入客户端 IP 信息：-第一层负载均衡设备上，配置虚拟服务器，启用 proxy_protocol 功能；-第二层负载均衡设备上，新建一个 HTTP 配置模板。选择通过 proxy_protocol的方式获取客户端 IP 地址，并将客户端 IP 地址插入至 X-Forward-For 头信息中。最终，将此配置模板绑定到虚拟服务器上；-客户端发起访问，并在第二层负载均衡设备上抓包；（3）声明插入的源地址版本是 IPv4 还是 IPv6：-创建负载均衡应用池和虚拟服务器；-开启客户端地址携带：“应用负载”“配置模板”“TCP&UDP 模板”：找到“客户端 IP 地址携带(TCP option)”，点击启用，并配置可选前缀为：src-IPv4；客户端发起访问，并在负载均衡设备上抓包。预期结果：（1）通过 TCP option 插入时，真实服务器收到的数据包可以显示插入的 TCP 2022 年数字时代应用可持续性架构与验证白皮书 48 option 信息；（2）通过 payload 插入时，负载通过先提取 payload 信息，再转存到 XFF 字段转发给后台真实服务器；（3）真实服务器收到数据包的 TCP option 字段中可以显示自定义的前缀信息。9、连接镜像功能 测评目标：验证设备是否支持连接镜像功能。功能说明及应用场景：（1）支持长连接镜像功能，即主备设备间连接表实时同步，在主设备故障的情况下，切换到备机后不影响原有长连接的访问；（2）支持只针对特定的虚服务开启连接镜像功能，并且连接镜像和会话同步两个功能可分开进行设置。测试步骤：（1）建立一个 VS，开启连接镜像功能，客户端发起到这个 VS 的 Telnet 和 FTP 的长连接访问。确认主备设备的连接表是否同步；（2）切换主备机后，查看原有长连接是否正常连接。预期结果：（1）Telnet 和 FTP 的访问均正常，连接表实时同步，支持长连接镜像功能，即主备设备间连接表实时同步，在主设备故障的情况下，切换到备机后不影响原有长连接的访问；（2）支持只针对特定的虚服务开启连接镜像功能，并且连接镜像和会话同步两个功能是可以分开进行设置的。10、服务器温暖上线 测评目标：验证服务器温暖上线。功能说明及应用场景：在设定的时间内，按照一定的规律逐渐给新启用的服务器分配连接，超过设定的时间后，按照预设的负载均衡算法进行服务器的连接分配。测试步骤：（1）负载均衡服务器上将应用池中的一个真实服务器配置启用温暖上线功能，并将其 disable；（2）客户端以一定压力访问虚拟服务，通过服务器运行状态查看真实服务器的状态；（3）在负载均衡器上将应用池中的真实服务器 enable，通过服务器运行状态查看真实服务器的状态。2022 年数字时代应用可持续性架构与验证白皮书 49 预期结果：（1）客户端以一定压力访问虚拟服务器，通过服务器运行状态查看流量按照负载均衡算法分发给后端的真实服务器；（2）客户端的访问不中断，负载均衡服务器上 enable 启用了温暖上线功能的真实服务器后，通过服务器运行状态查看此真实服务器在恢复时间内没有新的连接，在之后的温暖时间内连接逐渐增加至与其他真实服务器接近。11、SSL 卸载功能 测评目标：验证国密/非国密 SSL 卸载功能。功能说明及应用场景：（1）负载均衡设备支持同时对 TLS 版本和密码套件算法进行自定义，并且 TLS 版本支持 TLS1.0-TLS1.3；（2）能够按照配置密码套件的优先级顺序进行匹配；（3）SSL 弱算法过滤；（4）支持 SSL 的双向证书认证模式；（5）验证是否支持国密 SSL 单向卸载；（6）验证是否支持国密 SSL 双向卸载；（7）验证是否支持 SM2、SM3、SM4 算法；（8）验证同一站点是否同时支持国际/国密证书自适应。测试步骤：（1）SSL 模板中启用 SSL 卸载功能，分别设置不同的 SSL 协议版本和对应的密码套件；（2）客户端访问绑定 SSL 模板的虚拟服务器，抓包确认 SSL 协商使用的协议版本及套件；（3）验证是否支持 SSL VS 配置 SSL 算法优先选择功能；（4）验证是否支持 SSL VS 配置 SSL 弱算法过滤功能；（5）配置 SSL 模板，启用双向认证，分别配置强制认证和非强制认证；（6）客户端访问绑定配置双向认证 SSL 模板的虚拟服务器，验证 SSL 强制认证和非强制认证是否成功；（7）SSL 模板启用 SSL 卸载功能，选择国密 SSL 协议，禁用双向认证；（8）客户端访问绑定国密协议的 SSL 模板的虚拟服务器，验证国密 SSL 访问是否成 2022 年数字时代应用可持续性架构与验证白皮书 50 功；（9）SSL 模板启用 SSL 卸载功能，选择国密 SSL 协议，启用双向认证；（10）客户端访问绑定国密协议的 SSL 模板的虚拟服务器，验证国密 SSL 双向认证访问是否成功；（11）SSL 模板启用 SSL 卸载功能，选择国密 SSL 协议，密码套件选择 ECDHE-SM4_128_CBC_SM3；（12）使用支持密码套件 ECDHE_SM2_WITH_SM4_128_CBC_SM3 的国密客户端访问绑定 SSL 模板的虚拟服务器；（13）SSL 模板密码算法启用国密/国际标准算法，同时配置国际和国密服务器证书；（14）使用优先 RSA 算法的浏览器访问绑定 SSL 模板的虚拟服务器；（15）使用优先 ECC 算法的浏览器访问绑定 SSL 模板的虚拟服务器。预期结果：（1）设备支持 TLS1.0-TLS1.3 版本，支持同时对 TLS 版本和密码套件算法进行自定义，客户端支持的密码套件与负载配置的套件匹配，访问虚拟服务同时抓包确认使用的SSL 协议版本和密码套件算法是否为配置的算法；并且能够按照配置密码套件的优先级顺序进行匹配；（2）支持 SSL 弱算法过滤功能；（3）支持 SSL 的双向证书认证模式，包括强制和非强制认证，当客户端证书认证失败返回定制页面；（4）设备支持国密协议 SSL，单向卸载功能正常；（5）设备支持国密协议 SSL，双向卸载功能正常；（6）客户端访问虚拟服务器成功，SSL 通过ECDHE_SM2_WITH_SM4_128_CBC_SM3 协商成功；（7）使用优先 RSA 算法的浏览器访问虚拟服务，SSL 协商过程服务端发送 RSA 站点证书到客户端；（8）使用优先 ECC 算法的浏览器访问虚拟服务，SSL 协商过程服务端发送 ECC 站点证书到客户端。12、动态路由功能（IPv4/IPv6 双栈）测评目标：验证设备是否支持动态路由功能。功能说明及应用场景：查看路由表，同时支持 IPV4 和 IPV6 的 VS/SNAT 的 2022 年数字时代应用可持续性架构与验证白皮书 51 OSPF/BGP 路由条目，并且切换后路由条目收敛正常。测试步骤：（1）测试设备配置 OSPFv2 和 OSPFv3（IPv6）；（2）测试设备配置独立的 SNAT 地址网段,可以通过 OSPF 路由发布出去；（3）查看路由表，同时支持 IPV4 和 IPV6 的 VS/SNAT 的 OSPF 路由条目；（4）手工切换，访问虚拟服务，备机接管流量，VS/SNAT 路由条目收敛正确，切换到备机；（5）按照上述步骤测试设备是否支持 BGP 的动态路由协议。预期结果：（1）查看路由表，同时支持 IPV4 和 IPV6 的 VS/SNAT 的 OSPF 路由条目，并且切换后路由条目收敛正常；（2）查看路由表，同时支持 IPV4 和 IPV6 的 VS/SNAT 的 BGP 路由条目，并且切换后路由条目收敛正常。13、主备模式高可用功能 测评目标：测试负载均衡设被的主备高可用功能。功能说明及应用场景：（1）设备支持主备、主主、N M 部署模式；（2）支持手工触发设备的主备切换；（3）故障自动切换条件：设备故障、设备关机/断电,监控 VLAN 无流量、监控网关IP 不通；（4）双心跳：带内、带外管理双心跳；（5）当有单个 VS 切换需求的情况下，可以正常进行切换，保证 VS 和该 VS 关联的SNAT 的地址都能够切换。测试步骤：（1）两台设备采用单臂的组网模式，同时端口要进行捆绑，完成基础的网络配置；（2）分别在命令行和 Web 界面触发设备的主备切换，验证主备是否正确切换，同时查看交换机 ARP 表验证是否正确更新；（3）配置监控策略-监控 VLAN 的功能，验证该机制是否工作正常；（4）配置监控策略-监控网关的功能，验证该机制是否工作正常；（5）配置 Network Failover 功能，断开 Network Failover 和管理口的连线，验证 2022 年数字时代应用可持续性架构与验证白皮书 52 是否双活；连接 Network Failover 连线，验证是否主备状态是否正常恢复。预期结果：（1）同时支持通过 Web 界面和命令行两种方式触发设备的主备交换，并且交换机侧ARP 表正确更新；（2）监控策略-监控 VLAN 功能正常，相应的 VLAN 内没有流量的情况下会触发设备的主备切换；（3）监控策略-监控网关功能正常，对应的探测节点故障的情况下会触发设备的主备切换；（4）备份心跳工作正常，可支持同时配置业务口和管理口作为设备的心跳，同时中断的情况下负载均衡出现双活，其中一组端口故障的情况下主备状态不变。14、N M 集群功能 测评目标：验证在 N M 多主集群的功能是否正常。功能说明及应用场景：（1）设备支持主备、主主、N M 部署模式；（2）支持手工触发设备的主备切换；（3）故障自动切换条件：设备故障、设备关机/断电,监控 VLAN 无流量、监控网关IP 不通；（4）双心跳：带内、带外管理双心跳；（5）当有单个 VS 切换需求的情况下，可以正常进行切换，保证 VS 和该 VS 关联的SNAT 的地址都能够切换。测试步骤：（1）首先由 A1,B1,C1 组成集群；（2）A1 发生设备，变更，配置变更可以同步到集群设备中；（3）TG1，TG2 分别绑定不同的浮动 IP；TG1 活在 A1，TG2 活在 B1；TG1 的切换顺序为 A1-B1-C1,TG2 的切换顺序为 B1-A1-C1；（4）按照预定策略顺序模拟故障的情况下，验证设备是否可以正常切换（采用设备强制脱机方式模拟故障）；（5）验证设备是否支持在不改变配置的切换顺序的情况下，手工强制将 TG 切换到指定的设备上；（6）验证设备的备份心跳机制是否正常；2022 年数字时代应用可持续性架构与验证白皮书 53（7）监控 VLAN 功能正常，相应的 VLAN 内没有流量（物理接口 up）的情况下会触发设备的主备切换。预期结果：（1）支持 Web 端增加设备，并向集群设备同步功能；（2）A1 修改设备信息，配置信息，可以通知集群中的所有设备；（3）A1 设备强制脱机，此时 TG1 切换到 B1 上，TG2 不变仍然在 B1；（4）模拟故障情况下，TG 可以按照预定的策略进行切换；（5）在不改变配置的切换顺序的情况下，支持手工强制将 TG 切换到指定的设备上；（6）设备的备份心跳机制工作正常，同时配置业务口和管理口作为设备的心跳，同时中断的情况下负载均衡出现双活，其中一组端口故障的情况下主备状态不变；（7）设备的监控 VLAN 机制工作正常，相应的 VLAN 内没有流量（物理接口 up）的情况下会触发设备的切换。三、超高可用架构场景测试 1、超高可用架构协同集成功能 测评目标：验证两层负载均衡设备实现应用流量智能分流的超高可用架构功能。功能说明及应用场景：构建超高可用性的应用智能分流解决方案。（1）在信创与非信创区域混合场景下，利用两层负载均衡架构构建超高可用性实现不同区域的应用智能分流；（2）顶级负载均衡设备可以通过私有协议与不同区域的二级负载均衡设备联动集成；（3）顶级负载均衡设备通过周期性获取二级负载均衡设备的运行压力以及可用应用系统服务资源数量变化，实时动态的调整应用分流权重比率。测试步骤：（1）配置二级负载均衡设备，创建应用虚拟服务器，对应的应用池成员为本区域真实提供应用系统服务的服务器资源；（2）在二级负载均衡设备上设置压力阈值（流量吞吐阈值、并发连接阈值和连接新建阈值）；（3）配置顶级负载均衡设备，创建应用虚拟服务器，对应的应用池成员分别为信创区域和非信创区域甚至其他区域提供相同应用系统服务的二级负载均衡设备上的应用虚拟服务器；2022 年数字时代应用可持续性架构与验证白皮书 54（4）顶级负载均衡设备根据理想预期模型，对应用池成员设置权重比率。正常情况下，顶级负载均衡设备根据预置的权重按比率调度应用流量给二级负载均衡设备；（5）同时增加业务压力，使得某二级负载均衡设备的应用流量压力超过阈值（任何一个超限即可）；（6）等待一段时间后，在顶级负载均衡设备上查看对应的二级负载均衡设备上的应用池成员权重比率是否降低。在二级负载均衡设备上查看应用流量压力是否降低；（7）在二级负载均衡设备上禁用应用池成员，或关闭部分应用系统服务器；（8）在顶级负载均衡设备上查看对应的二级负载均衡设备上的应用池成员权重比率是否降低。在二级负载均衡设备上查看应用流量压力是否降低。预期结果：顶级负载均衡设备可以自动感知二级负载均衡设备的压力和可用应用系统资源数量变化，并动态调整分流比率。2、Kubernetes 环境集成实现四层虚拟服务器自动创建 测评目标：验证 Kubernetes 环境集成是否能实现四层虚拟服务器自动创建。功能说明及应用场景：Kubernetes 环境集成实现四层虚拟服务器自动创建。测试步骤：（1）通过 Kubernetes deployment 资源创建 FTP 服务的 Pod 对象，作为真实服务器；（2）通过 Kubernetes services 资源创建对象，作为应用池；（3）通过 Virtual Servers 自定义资源创建对象，作为虚拟服务器。预期结果：Kubernetes 环境集成实现四层虚拟服务器自动创建。3、Kubernetes 环境集成实现七层虚拟服务器自动创建 测评目标：验证 Kubernetes 环境集成是否能实现七层虚拟服务器自动创建。功能说明及应用场景：Kubernetes 环境集成实现七层虚拟服务器自动创建。测试步骤：（1）通过 Kubernetes deployment 资源创建 HTTP 服务的 Pod 对象，作为真实服务器；（2）通过 Kubernetes services 资源创建对象，作为应用池；（3）通过 Virtual Servers 自定义资源创建对象，作为虚拟服务器。预期结果：Kubernetes 环境集成实现四层虚拟服务器自动创建。2022 年数字时代应用可持续性架构与验证白皮书 55 4、Kubernetes 环境集成实现真实服务器自动扩容和缩减 测评目标：验证 Kubernetes 环境集成是否能实现真实服务器自动扩容和缩减。功能说明及应用场景：Kubernetes 环境集成实现真实服务器自动扩容和缩减。测试步骤：（1）通过 Kubernetes deployment 资源创建 HTTP 服务的 Pod 对象，作为真实服务器；（2）通过 Kubernetes services 资源创建对象，作为应用池；（3）通过 Virtual Servers 自定义资源创建对象，作为虚拟服务器；（4）增加 deployment 资源对象的 Pod 数量，查看虚拟服务真实服务器是否增加；（5）减少 deployment 资源对象的 Pod 数量，查看虚拟服务真实服务器是否减少。预期结果：Kubernetes 环境集成实现四层虚拟服务器自动创建。5、集中管理平台统一纳管功能 测评目标：验证集中管理平台是否支持纳管多种类型的资源。功能说明及应用场景：集中管理平台具备统一纳管能力，协助用户管理传统数据中心负载均衡设备和云原生的 NGINX 软件产品。（1）集中管理平台通过 Agent 插件纳管 NGINX OSS 和 NGINX Plus 资源；（2）集中管理平台通过 API 调用纳管 TML-ADC 和 BIGIP 设备；（3）纳管的资源实例正常运行后，可在仪表盘页查看相应资源的运行指标数据，进行多指标监控，同时可通过数字图，折线图等多样式自定义展示指标数据。测试步骤：（1）集中管理平台纳管方式：-集中管理平台通过 Agent 上报方式获得 NGINX OSS、NGINX Plus 资源相关信息建立平台与资源纳管关系，且可通过配置文件的“zone_name”字段值使对应域权限的用户可看到对应的资源信息，也可通过在集中管理平台中新建资源输入相关信息建立平台与对应资源的纳管关系；-TMLake 和 BIGIP 类资源通过在集中管理平台手动添加资源来纳管资源（2）NGINX OSS、NGINX Plus 类资源配置上游服务器池（负载均衡算法可选用固定算法“轮询、哈希”，也可勾选“高级”自定义算法）、配置虚拟服务器（可自定义配置，也可通过配置模板选择模板配置还可以选择代码模式直接编写代码配置）；（3）NGINX OSS、NGINX Plus 类资源可配置资源，之后在发布列表新建发布选择 2022 年数字时代应用可持续性架构与验证白皮书 56 对应的要发布的资源进行发布，或直接手动发布（2 种方式：手工输入代码或选择之前已发布版本进行更改后发布）；（4）NGINX OSS、NGINX Plus、TMLake、BIGIP 类资源在仪表盘中可新建仪表盘监控指标，查看对应资源的指标数据变化；-NGINX OSS 资源指标有“CPU 使用率、内存使用率、活动连接、新建连接、已处理连接数、总请求数、正在写连接数、正在读连接数、正在等待连接数”；-NGINX plus 资源指标有“CPU 使用率、内存使用率、活动连接、新建连接、连接丢失、上游服务器响应时间、上游服务器通讯失败、空闲连接数、当前请求数、总请求数量、总 SSL 握手数、SSL 握手失败数、SSL 会话重用数”；-TMLake 资源指标有“CPU 使用率、内存使用率、流量、TCP 新建、TCP 并发、HTTP 请求”；-BIGIP 资源指标有“CPU 使用率、内存使用率、吞吐量、连接数”；-在对应的指标图表上可以进行筛选时间，观察对应时间内指标数据变化，有些指标图表也可勾选或点击对应资源名称查看对应资源指标数据。预期结果：（1）在集中管理平台左侧选择资源类型，在“资源列表”可看到对应的纳管资源,若是不同域的资源，需要对应域的用户才能看到资源；（2）通过虚拟服务器可将它与上游服务器池做关联；（3）发布后，可在发布列表中看到发布记录，了解到发布状态；（4）在对应仪表板可查看到添加的指标图表数据变化。6、TML-ADC/BIGIP 设备批量升级功能 测评目标：验证 TML-ADC/BIGIP 的批量升级功能。功能说明及应用场景：通过集中管理平台可以为 TML-ADC/BIGIP 设备提供批量软件升级功能，实现软件版本集中升级管控。测试步骤：（1）准备 TML-ADC 设备两台，BIGIP 设备两台；（2）进入集中管理资源管理，将 4 台设备添加到集中管理平台通过 API 的方式进行纳管；（3）进入集中管理平台-进入一级菜单切换页选择资源类型-升级-升级包，上传升级所需文件（TMLake 升级文件格式为.gpg，BIGIP 升级文件格式为.ios）；2022 年数字时代应用可持续性架构与验证白皮书 57（4）进入集中管理平台-升级-升级列表-新建升级，选择要升级的资源和版本,进行升级；（5）等待大约 40 分钟。预期结果：（1）集中管理平台-升级-升级列表 升级的状态为升级成功；（2）登录 TML-ADC 设备/BIGIP 设备，查看是否升级成功。7、TML-ADC/BIGIP 配置备份功能测试 测评目标：验证 TMLake/BIGIP 配置备份功能。功能说明及应用场景：（1）配置备份功能，可以通过集中管理平台 Web 管理界面,为 TML-ADC/BIGIP 设备提供备份相关功能；（2）TML-ADC 配置相关的功能包括：新建备份，备份上传，恢复初始备份，备份的下载，恢复及删除功能；（3）BIGIP 备份相关的功能包括：新建备份，备份上传，备份的下载，恢复及删除功能。测试步骤：（1）进入集中管理平台-进入一级菜单切换页选择资源类型-备份-选择资源；（2）点击新建备份；（3）选择配置文件上传；（4）点击下载文件；（5）恢复文件。预期结果：（1）集中管理平台新建备份成功，登录 TML-ADC 设备/BIGIP 设备，可以查看到集中管理平台新建的备份；（2）集中管理平台备份文件成功，登录 TML-ADC 设备/BIGIP 设备，可以查看到集中管理平台上传的备份文件；（3）集中管理平台上传和新建的备份文件可以在集中管理平台下载成功；（4）选择配置文件进行恢复，登录 TML-ADC 设备/BIGIP 设备查看备份恢复成功。8、NGINX/TML-ADC/BIGIP 日志管理功能 测评目标：验证 NGINX/TML-ADC/BIGIP 日志管理功能。2022 年数字时代应用可持续性架构与验证白皮书 58 功能说明及应用场景：（1）通过集中管理平台可以为 NGINX/TML-ADC/BIGIP 设备提供多类型的日志集中管理及检索查询功能；（2）针对 NGINX 可查看和筛选的日志的类型有访问日志，错误日志；（3）针对 TML-ADC/BIGIP 设备可查看和筛选的日志的类型有升级日志，访问日志，安全日志，系统日志。测试步骤：（1）登录集中管理平台，进入一级菜单切换页选择资源类型-日志中心；（2）选择要查看的日志类型；（3）对日志进行时间筛选；（4）对关键字进行筛选。9、集中管理平台告警功能 测评目标：验证集中管理平台是否支持告警功能。功能说明及应用场景：（1）集中管理平台已成功纳管资源类型为：NGINX OSS 和 NGINX Plus、TML-ADC 和 BIGIP 的资源；（2）通过告警功能可定制告警规则，触发告警规则后可发邮件或短信给设置的联系人。测试步骤：（1）集中管理平台通过左上方菜单，选择 NGINX、TML-ADC、BIGIP 资源类型，进入相关资源的配置操作页面；（2）在“规则列表”中，可看到规则列表，展示已建的告警规则，且可进行规则的“启用/禁用/修改”操作，也可添加规则，点击添加规则；（3）所有资源类型的添加规则页面输入项都是相同的，但是在后续的选项中有各自的特点；（4）告警规则建立完成后，默认启用，触发相应的规则。预期结果：（1）可看到“告警模块”；（2）进入添加规则页面；（3）资源类型选择：2022 年数字时代应用可持续性架构与验证白皮书 59-资源类型选择不同类型，则在“资源”下拉选中显示对应类型的资源实例；-告警源根据所选资源，下拉展示：NGINX OSS 和 NGINX Plus 类资源显示为“CPU 使用率、内存使用率、磁盘使用率、日志”，选择“日志”则会进一步让选择为“访问日志、错误日志”；TML-ADC 类资源显示为“CPU 使用率、内存使用率、磁盘使用率、链路、CPU 温度、日志”，选择“日志”则会进一步让选择为“审计日志、访问日志”;BIGIP 类资源显示为“CPU 使用率、内存使用率、磁盘使用率、日志”，选择“日志”则会进一步让选择为“审计日志、访问日志、安全日志、系统日志”；（4）可以在“告警信息”列表中显示告警信息，同时根据告警规则中选择的“联系人”，发送邮件或者短信。四、管理功能测试 1、配置文件备份和恢复 测评目标：验证配置文件备份和恢复功能。功能说明及应用场景：（1）配置文件可以正常备份和恢复；（2）HA 模式下配置可以正常在设备间进行同步。测试步骤：（1）登录设备，保存设备的配置文件；（2）任意修改一些配置，然后恢复设备配置，确认配置文件恢复功能是否正常；（3）修改其中一台设备配置，将配置同步到设备组。预期结果：（1）配置文件可以正常备份和恢复；（2）HA 模式下配置可以正常在设备间进行同步。2、数据统计和报表功能 测评目标：验证数据统计功能。功能说明及应用场景：（1）支持数据统计功能，Web 界面可以查看历史 30 天的系统性能数据，至少包括整备整体的 CPU、内存、新建连接、并发连接、吞吐的统计；（2）支持每个 VS、pool、member 的实时连接数据等业务数据的统计。2022 年数字时代应用可持续性架构与验证白皮书 60 测试步骤：验证是否支持对常用的指标的统计功能，包括不但不限于设备全局信息的统计（如 CPU、内存、新建连接、并发连接、吞吐等）、针对 VS 和针对 member 等的详细统计信息。预期结果：（1）支持数据统计功能，Web 界面可以查看历史 30 天的系统性能数据，至少包括设备整体的 CPU、内存、新建连接、并发连接、吞吐的统计；（2）支持每个 VS、pool、member 的实时连接数据等业务数据的统计。3、网络管理扩展功能 测评目标：验证 Web 管理界面是否实现 MAC 地址表、ARP 表及路由表增加、删除和查看功能。功能说明及应用场景：可以通过 Web 管理界面针对 MAC 地址表、ARP 表及路由表实现增加、删除和查看功能。测试步骤：（1）点击增加按钮创建一条 MAC 地址记录；选中此记录，点击删除按钮删除此记录；（2）点击增加按钮创建一条 ARP 记录；选中此记录，点击删除按钮删除此记录；（3）静态路由页面点击增加按钮创建一条静态路由记录；点击删除按钮删除此记录；（4）策略路由页面点击增加按钮创建一条策略路由记录；选中此记录，点击删除按钮删除此记录。预期结果：（1）Web 管理界面可以实现 MAC 地址记录的增加、删除和查看操作；（2）Web 管理界面可以实现 ARP 记录的增加、删除和查看操作；（3）Web 管理界面可以实现静态路由记录的增加、删除和查看操作；（4）Web 管理界面可以实现策略路由记录的增加、删除和查看操作。4、运维管理工具 测评目标：验证 Web 管理界面是否提供图形化系统诊断工具。功能说明及应用场景：通过 Web 管理界面提供图形化系统诊断工具，包括 ping、traceroute、tcpdump、netstat、iostat、pktdump、sar、GratuitousARP、arpping、ndisc6、wget、curl、dig 功能。测试步骤：（1）诊断工具页面，查看支持的诊断命令；2022 年数字时代应用可持续性架构与验证白皮书 61（2）选择诊断命令，填写需要的参数后，执行命令。预期结果：（1）页面支持 ping、traceroute、tcpdump、netstat、iostat、pktdump、sar、GratuitousARP、arpping、ndisc6、wget、curl、dig 诊断命令；（2）填写命令参数后执行正常，页面可查看命令执行结果。5、Syslog 功能 测评目标：验证单电源故障场景，Syslog 服务器能否正常收到告警日志。功能说明及应用场景：（1）模拟单电源故障场景，Syslog 服务器能够正常收到告警日志；（2）Syslog 支持根据日志等级和日志类型等条件进行过滤。测试步骤：（1）进入【故障诊断】的告警管理，选择 Syslog 告警，选择启用，需要告警的事件等级、类型以及 Syslog 服务器地址；（2）断掉电源 2，在远端的 Syslog 服务器中查看到电源 2 异常的日志。预期结果：单电源故障场景，Syslog 服务器可以正常收到告警日志。6、SNMP 与 NTP 功能 测评目标：验证 NTP 功能是否正常。功能说明及应用场景：（1）支持设置 NTP，且时间能跟 NTP Server 同步，修改 NTP Server 时间，设备可以同步时钟；（2）支持多个 NTP Server 地址的设置。测试步骤：（1）将 SNMP 的服务器指向行内网管服务器；（2）验证在 SNMP 服务器上是否能够获取如下 MIB 值信息：CPU 利用率、内存利用率、吞吐和新建连接数；（3）添加 NTP Server1 地址，保存配置后，验证时钟是否成功同步；（4）修改 NTP Server1 时钟，验证时钟同步是否正确；（5）添加备用 NTP Server2 地址；（6）NTP Server1 故障，修改设备时间后，查看能否同步 NTP Server2 的时间。预期结果：2022 年数字时代应用可持续性架构与验证白皮书 62（1）网管服务器能够正常采集到设备的相关信息，不但能够针对设备的整体指标进行采集，还能够针对指定的 VS 的新建和并发连接数进行采集，并且采集结果和设备上查看的结果一致，同时支持 SNMPv2 和 SNMPv3 版本；（2）设备支持设置 NTP，可以同步 NTP Server 的时间；（3）支持多个 NTP 地址设置，其中一个 NTP 服务故障可以通过另一个 NTP 服务同步时间。7、API 接口 测评目标：验证 API 接口功能。功能说明及应用场景：（1）提供 soap 和 Restful 的 API 接口，兼容主流 Python、Terraform 官方模块等方式调用；（2）API 支持配置抓取、新增、修改、删除配置，以及配置同步和保存；可通过 API进行设备、VS、member 的在线和离线状态读取；可通过 API 对整机进行 force offline、主备切换、流量组切换。测试步骤：（1）验证设备是否支持通过 API 接口完成设备配置抓取、新增、修改、删除配置，以及配置同步和保存；（2）验证设备是否支持通过 API 接口完成设备在线和离线状态读取；（3）验证设备是否支持通过 API 接口完成整机 force offline、主备切换、流量组切换。预期结果：（1）API 支持配置抓取、新增、修改、删除配置，以及配置同步和保存；（2）可通过 API 进行设备、VS、member 的在线和离线状态读取；（3）可通过 API 对整机进行 force offline、主备切换、流量组切换。8、Web/CLI/API 管理功能 测评目标：验证设备是否同时支持 Web 图形化、命令行、Restful API 运维管理能力。功能说明及应用场景：设备必须同时支持 Web、命令行、Restful API 运维管理方式。测试步骤：（1）Web 配置及常规运维信息获取；（2）命令行配置及常规运维信息获取；2022 年数字时代应用可持续性架构与验证白皮书 63（3）Restful 配置及常规运维信息获取。预期结果：设备同时支持 Web、命令行、Restful 配置及常规运维信息获取。2022 年数字时代应用可持续性架构与验证白皮书 64 第五章 展望 纵观应用可持续性架构的发展过程，从以“商务区体验区”构建的双区运营的双活架构，到基于 4/7 层分离的双模 IT 架构，再发展至如今的以灰度割接构建的双轨信创架构，应用可持续性架构在每一阶段都不断夯实基础。未来将以算力网络技术为主的云网融合网络架构演进，将对应用交付高可用性提出更高的要求。云网融合，是指云计算与通信网相融合，即将网络技术引入至云计算中，与此同时在通信网中引入云计算技术。算力作为推动数字经济发展的主引擎动力，成为数字化时代的基础设施。算力网络的建设和发展过程可以分为三个阶段：泛在连接，即强化算网连接属性，形成具有包容性、互联互通的算力和网络基础资源池；融合感知，即基于对业务场景和资源池的感知体系，形成算与网融合调度的新型运营模式；无感调用，即算力网络突破固有的物理空间限制，在端与端间建立确定性算力连接，让用户无感、无限使用算力。目前算力网络处于“泛在连接”阶段，主要由运营商牵头各研究院和相关组织共同立项开展研究，同时推进大型数据中心和异构算力层面的算网资源补齐。随着国家战略的牵引，运营商将与产学研各界及与终端用户服务商通力合作，统一算力网络行业标准、突破算网融合技术并优化场景应用，以推进算力网络往融合感知、无感调用阶段发展。在算力网络时代下，对应用可持续性架构提出了五个更高的要求：（1）可靠性方面，应保证应用服务在要求时间内始终处于可用状态；（2）可恢复性，当外界发生事故造成宕机时，应用需更快速恢复正常服务状态；（3）可伸缩性，由于算力网络的变化与增长迅速，应用具有更高的可伸缩性以适应算网的变化；（4）可监控性，应用运行情况复杂，需要持续并高频地监控及分析。（5）可维护性，应用的维护和升级频率将会更加频繁，因此需要应用具备更高的可维护性，以便应用迭代与维护。这些都要求，在未来算力网络架构下的应用可持续要具有更强的软件定义特性、安全特性和 AI 特性。软件定义是指整个算力网络可以视作一个大号操作系统（平台），计算、存储的资源供给节点的“随机”热进、热出，必须能被算力网络本身感知，而资源消耗节点的使用和释放，同样能被感知，两者再进行匹配、自适应，最终形成类似于电网的复杂自适应系统。安全将贯穿到每一个环节，而不再是在最后作为一个特性加入其中，其将在目前应用可持续中安全编排的基础上进一步升级，以 DevSecOps 的形态贯穿始终，并与软件安全信息共享(S-SIS)、攻击模拟(AT)和威胁情报(TI)结合起来，以提高系统的安全性。AI 则在动态负载、自动化测试、混沌工程等诸多场景发挥作用，并将逐步实现从“故 2022 年数字时代应用可持续性架构与验证白皮书 65 障节点剔除和替换”到“故障节点修复”的逐渐升级。2022 年数字时代应用可持续性架构与验证白皮书 66 特别鸣谢 神州云科、通明湖云和信创研究院、通明智云、F5 基于多年在超高可用架构、应用可持续性、应用交付、负责均衡等领域的专业知识和行业经验，在本报告撰写过程中与艾瑞咨询团队开展了深入沟通，支持了报告涉及的专业知识和企业实践等内容的形成，艾瑞咨询对参与本报告的专家表示感谢：李 刚 通明湖云和信创研究院院长 吴静涛 神州云科副总裁，通明湖云和信创研究院副院长 常 旭 F5 解决方案顾问 张 刚 通明智云产品总监 2022 年数字时代应用可持续性架构与验证白皮书 67 附录：应用可持续性架构测试示例 健康检查基本功能(IPv4/IPv6 双栈）4 测评目标 健康检查基本功能测试(IPv4/IPv6 双栈）测 试 人 功能说明及应用场景 健康检查是 SLB 应用场景中最重要的基础技术之一，通过它来检测应用服务器运行是否正常。虚拟服务器在流量调度时依据应用池成员的健康状态，始终将应用流量转发给运行正常的应用服务器。为了更加准确的检测到应用服务器健康状态，负载均衡设备应该具备丰富的健康检查手段，包括：1.基本的健康检查方法包括：ICMP、TCP、TCP 半连接、UDP、HTTP、HTTPs 等类型；2.支持深度定制的健康检查方法，包括：HTTP2.0 健康检查、数据库查询健康检查、主从数据库状态的健康检查、定制 TCP 携带指定字符串健康检查等；3.针对深度定制的脚本化健康检查方法，应该可以通过 Web 管理界面方面查看和编辑脚本（Perl 或 Python 等）测试步骤 1.创建健康检查，健康检查类型分别选择 ICMP、TCP、TCP 半连接、UDP、HTTP 和 HTTPs，探测的频次和时间进行自定义配置。同时验证健康检查机制是否生效；2.创建 TCP socket 脚本类型健康检查，在 TCP 报文中携带指定字符串，验证是否可以收到约定返回值。如果返回值符合预期则认为应用服务器运行正常，否则判定健康状态异常；3.创建 HTTP2.0 脚本类型健康检查，负载均衡设备将使用 HTTP2.0 协议检测应用服务器；4.创建数据库查询脚本类型健康检查，通过管理界面调整数据库查询指令，验证是否可以收到约定的返回值。如果返回值符合预期则认为数据库服务器运行正常，否则判定健康状态异常；5.创建判断主从数据库状态的脚本类型健康检查，根据数据库主从状态判断应用服务器健康状态；4 示例测试环境采用通明智云 2022 年数字时代应用可持续性架构与验证白皮书 68 6.以上脚本类型健康检查方法，可以通过 Web 管理界面进行查询和修改操作；7.应用池中绑定对应的健康检查，查看应用池中成员的健康检查状态，抓包查看负载均衡设备到应用服务器之间的健康检查数据 预期结果 1.设备支持 ICMP、TCP、UDP、HTTP、HTTPs 健康检查方法，支持通过健康检查检查到服务器真实状态。当应用服务器故障，健康检查状态为异常（down）。当应用服务器工作正常，健康检查状态为正常（up）；2.支持 TCP Socket 深度健康检查，TCP 请求携带指定字符串，收到约定的返回值则认为健康状态正常；3.支持 HTTP2.0 协议的健康检查；4.支持数据库的深度健康检查，发送数据库查询指令，收到约定的返回值认为正常，否则异常；5.支持数据库的深度健康检查，可以判断数据库的主从状态，只有主机状态的数据库服务器健康状态正常；6.Web 管理界面下支持配置/查看/编辑脚本（Perl 或 Python 等）的健康检查 测试记录 1.创建类型为 ICMP 的健康检查 抓包查看负载到真实服务器的健康检查数据 IPv4 地址 2022 年数字时代应用可持续性架构与验证白皮书 69 IPv6 地址 服务器 A 网络离线，查看真实服务器运行状态 故障恢复，观察真实服务器是否正常 2.创建类型为 TCP 的健康检查 抓包查看负载到真实服务器的健康检查数据 IPv4 地址 2022 年数字时代应用可持续性架构与验证白皮书 70 IPv6 地址 3.创建脚本类型的 TCP 半连接健康检查 应用池选择 TCP 半连接健康检查，查看应用池成员健康检查状态为 up 2022 年数字时代应用可持续性架构与验证白皮书 71 抓包查看健康检查数据报文,负载均衡设备收到真实服务器 SYN/ACK 报文后主动发送 RST 信息中止连接建立。减少健康检查对应用服务器所产生的会话消耗。IPv4 地址 IPv6 地址 宕掉真实服务器，查看健康检查状态为 down 查看 TCP 半连接健康检查抓包信息 2022 年数字时代应用可持续性架构与验证白皮书 72 4.创建类型为 UDP 的健康检查 抓包查看负载到真实服务器的健康检查数据 IPv4 地址 IPv6 地址 5.创建类型为 HTTP 的健康检查 2022 年数字时代应用可持续性架构与验证白皮书 73 抓包查看负载到真实服务器的健康检查数据 IPv4 地址 IPv6 地址 6.创建类型为 HTTPs 的健康检查 2022 年数字时代应用可持续性架构与验证白皮书 74 抓包查看负载到真实服务器的健康检查数据 7.创建 TCP_Socket 脚本类型健康检查，设置指定发送的字符串和预期返回值。2022 年数字时代应用可持续性架构与验证白皮书 75 抓包查看，设备发送 TCP 请求中包含配置的字段 返回至符合预期，应用池成员状态正常。8.创建 HTTP2.0 协议类型的脚本健康检查方法 2022 年数字时代应用可持续性架构与验证白皮书 76 HTTP2.0 协议健康检查查看抓包结果 9.创建数据库脚本类型健康检查方法，脚本文件上传成功。应用池关联脚本健康检查方法 test-mysql，查看应用池成员状态为 up；2022 年数字时代应用可持续性架构与验证白皮书 77 修改连接数据库的账户密码，查看健康检查状态为 down；通过页面编辑健康检查脚本文件,修改为正确的数据库密码，查看应用池成员健康检查状态为 up；10.创建检测数据库服务器主从状态脚本类型健康检查方法，上传脚本文件成功 2022 年数字时代应用可持续性架构与验证白皮书 78 通过页面编辑脚本，修改正确的数据库密码，并将健康检查方法 test-db2-primary 关联到应用池。提供数据库服务的应用池成员中，检测 DB2 数据库运行状态为主状态的成员健康状态正常（up），从状态的成员健康状态异常（down）。测试结果 符合预期结果 备注 2022 年数字时代应用可持续性架构与验证白皮书 79 公司介绍/法律声明 艾瑞咨询深耕研究咨询领域十九年，为客户解决商业决策问题的专业第三方机构。公司以“为商业决策赋能”为品牌理念，通过研究咨询等专业服务，助力客户提高对新经济产业的认知水平、盈利能力和综合竞争力。在数据和产业洞察的基础上，艾瑞咨询研究业务拓展至大数据研究、企业咨询、投资研究、新零售研究等方向，并致力于通过研究咨询的手段帮助企业认知市场，智能决策。版权声明 本报告为艾瑞咨询制作，其版权归属艾瑞咨询，没有经过艾瑞咨询的书面许可，任何组织和个人不得以任何形式复制、传播或输出中华人民共和国境外。任何未经授权使用本报告的相关商业行为都将违反中华人民共和国著作权法和其他法律法规以及有关国际公约的规定。免责条款 本报告中行业数据及相关市场预测主要为公司研究员采用桌面研究、行业访谈、市场调查及其他研究方法，部分文字和数据采集于公开信息，并且结合艾瑞监测产品数据，通过艾瑞统计预测模型估算获得；企业数据主要为访谈获得，艾瑞咨询对该等信息的准确性、完整性或可靠性作尽最大努力的追求，但不作任何保证。在任何情况下，本报告中的信息或所表述的观点均不构成任何建议。本报告中发布的调研数据采用样本调研方法，其数据结果受到样本的影响。由于调研方法及样本的限制，调查资料收集范围的限制，该数据仅代表调研时间和人群的基本状况，仅服务于当前的调研目的，为市场和客户提供基本参考。受研究方法和数据获取资源的限制，本报告只提供给用户作为市场参考资料，本公司对该报告的数据和观点不承担法律责任。合作说明 该报告由神州云科、通明湖云和信创研究院、通明智云和艾瑞共同发起，旨在体现行业发展状况，供各界参考。联系我们 咨询热线 400 026 2099 联系邮箱 集团网站 http:/微信公号 艾瑞咨询官方微信 艾瑞咨询官方微博 数字时代应用可持续性架构与验证白皮书 1